From an implementation specialist's point of view (please feel free to refute my point of view), many of us differentiate "patches" from "updates" from "upgrades". Patches are relatively simple as long as we follow the instructions. It would be wonderful if updates to MOR builds were equally as simple but they are not.
Updates are challenging because every MOR build requires patches (i.e. upgrades or re-installs) to one or more of the third-party components: web server, servlet engine, LDAP, and database. The move to 9.1 M030+ was particularly notable because of the replacement of Aphelion with Windchill Directory Server. These kinds of changes require implementation specialist expertise which many companies get from their VARs or PTC Global Services.
From a QA perspective a temp patch is a relatively isolated change that can be spot checked with targeted testing. Automated regression/performance testing (for those customers who have developed it from scratch) will validate nothing else was broken by the temp patch. The rest of us have to do manual regression testing. This can take hours to weeks. The longer the process takes, the less willing customers are to update.
The balance of investment vs. payback I have seen is updating to every third or fourth maintenance build. That averages out to one update a year.
Eliminating software components from the Windchill installation would help from a software perspective. The removal of Tomcat in 10.0 (embedded in the Method Server) is a step in the right direction. Finding a way to eliminate the LDAP software component from the base installation would significantly simplify backups, updates, upgrades, and rehosting activities.
In Reply to Jess Holle:
I believe PTC and customers need to work together to understand why MOR
"upgrade" is difficult/expensive and address sources of this difficulty
wherever possible.
Certainly on PTC's part /every /effort should be taken not only to
ensure no regressions, but to ensure that any end-user UI changes or
additions are opt-in so as to provide as seamless a transition as
possible. I believe that at least on the regression testing front,
recent MORs have been much better than those in the past. PTC certainly
needs detailed feedback regarding customer MOR update experiences if
MORs are going to improve.
The reason I put "upgrade" in quotes is that upgrade/migration to me
applies only to changes between major versions, i.e. those requiring a
database upgrade/migration. Applying an MOR update should not have any
similarity to that level of effort or risk.
--
Jess Holle
P.S. I am speaking only for myself -- and not in any official capacity
for PTC here.
Jess,
We trust PTC QA to the extent that they can test software but customer testing is not optional. Look at the broader scope of hardware, software, and infrastructure. Add to this the integrated authoring tools, performance criteria, and the uniqueness of each company's data set. The configuration possibilities are limitless and beyond any software company's ability to QA completely. Only customer testing can truly qualify a customer environment and minimize deployment risk.
Maybe “MOR build requires” wasn’t the appropriate wording but it comes down to the same thing. Not updating these components to a software configuration that PTC has explicitly tested and qualified is additional risk that requires more rigorous customer QA. Our goal is to minimize the risk to the customer and minimize their in-house QA efforts.
I am interested in an out-of-the-box, easy-to-configure/use extensible QA tool for automated regression testing in the customer environment. I wouldn't complain if it addresses customizations but every customer must QA the post-update out-of-the-box software.
Regards,
Matt