Patches, Hot Fixes, and Upgrades
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-13-2014 06:53 AM
What is the best practice for applying patches, hot fixes and upgrades. Are there people that never upgrade or on the other extreme does any one apply ever hot fix the second it comes out. I asume that neither of thoes are true, but I am looking to know what method you follow and what gets you the best success.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-13-2014 07:51 AM
We were on the cutting edge with Dublin and now Eureka, mainly due to several fixes and features we were very interested in getting into production. However, we now include the QA team for full regression testing, and their process takes several weeks, during which we can't really do any major development. So, in the future, we'll probably slow down on upgrading to no more than every 3 quarters or so.
We're buying a second Dev instance so we can keep an upgrade path from sub-production to production at the same version, while a separate Dev -> QA path is on the next version for regression testing. Between upgrades we're using the second dev instance as a training / testing sandbox (using Team Development also).
Our upgrade procedure is to first clone Production back down to all sub-production instances. While QA is getting a baseline on the current version, we upgrade one dev instance to the next version. Then we look at the upgrade history to see what updates were skipped, and remediate as necessary (there were around 1,600 skipped updates for Eureka because we've customized stuff; we reverted about 160 items to Out-Of-Box). Once QA finishes their baseline review, we upgrade QA and apply our immediate fixes/reversions/feature release for them to do a full regression test. If they find additional things, we fix them in the upgraded Dev instance and promote them to QA.
Meanwhile, other miscellaneous requests go straight from the old non-upgraded Dev to Production.
Once QA signs off, we upgrade Production, apply all fixes, and then clone it back down to the sub-production instances. Regular development cycle picks back up after that.
Patches/hotfixes we do a single developer review and apply without full regression testing, since the hotfixes document the particular bug they're for. Each of these also need to have the Skipped updates list checked.