Upgrade Best Practices - Reverting Skipped Files

Tyson3
Tera Contributor

Hi,

I'm looking for some quick best practice guidance on the upgrade from Quebec to San Diego which we are currently working on. We have two sub instances ("Dev" and "Test") which we have already upgraded to San Diego. We are planning on upgrading our production instance to San Diego in July.

We are currently reviewing skipped files in our lowest instance "Dev" and are wondering about the best practice way to handle "Reverting to Base System" option. If we choose to revert a business rule for example, this change is tracked via an update set and then we can move the update set to the next sub environment "Test".  Should this update set be moved before or after we have upgrade our next instance? 

I have read some community posts with mixed signals with some saying you should move the update set to the next instance, and then upgrade.  Other ones say you should upgrade and then move the update set.   

Our assumption is the best practice is to track the skipped file in an update set first in your lowest environment and then move this update set to the next environments after it's already been upgraded.

Any clarification on this would be much helpful. Thanks!

5 REPLIES 5

Allen Andreas
Administrator
Administrator

Hi,

The update is moved AFTER the upgrade is done.

So essentially, only Dev would have been upgraded (this is so multiple environments aren't misaligned with the version and allows you to work on the fixes in the lowest environment first).

I wouldn't have had both Dev and Test upgraded and Test just sitting there while you all are working through your changes in Dev.

Only Dev should have been upgraded, you work through skipped changes, verify ATF and application functionality, full regression, etc.

Then, once everything appears good to go, Test is upgraded and right after that update set is moved from Dev to Test and committed. Then double-check things again in Test, you wouldn't work through the skipped changes all over again, as you've already done that in Dev.

Once Test is good, if anything is caught there, return to Dev, fix it, if applicable, make a second update set for those things, and then upgrade Prod, this time promote your main skipped changes fix AND the other update set (if applicable), and this time, lightly check things in Prod as best you can.

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Hi Tyson,

Just wanted to check-in and see how you're doing.

If my reply above helped guide you Correctly, please also mark as Correct.

Thanks and take care! 🙂


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Terri Kouba
Tera Expert

UC Berkeley Telecom Catalog instance does it in a similar way as expressed by Allen.  Note:  We have another instance which has a different process.

  1. we have 3 instances:  dev, test, prod
  2. Run pre-clone ATFs in dev and test
  3. clone dev and test at the same time.  Do post-clone activities
  4. run post-clone ATFs in dev and test
  5. upgrade dev
  6. in dev, do skip/revert/merges (some of which go into an update set)
  7. in dev, run post-upgrade ATFs
  8. in dev, validate system, post-upgrade
  9. in dev, export skip/revert decisions, close update set
  10. upgrade test
  11. in test, apply dev skip/revert decisions
  12. in test, apply post-upgrade update set
  13. in test, handle any extra skip/reverts
  14. in test, run post-upgrade ATFs
  15. in test, validate system
  16. in test, export skip/revert decisions
  17. upgrade prod
  18. in prod, apply test skip/revert decisions
  19. in prod, apply post-upgrade update set
  20. in prod, handle any extra skip/reverts
  21. in prod, non-invasive smoke-test to validate system

If you have any questions, please don't hesitate to ask.

Thanks,

Terri

 

---

Terri Kouba, ESM Service Manager
University of California, Berkeley
Berkeley Information Technology | Enterprise Service Management
Email: kouba@berkeley.edu
We champion diversity. We act with integrity. We deliver. We innovate.

Hi Terri - thanks for sharing this.  I can't seem to wrap my head around how applying the update set with the Replace on Upgrade after the prod upgrade helps.  Shouldn't these be set first, so that the upgrade replaces them with current and then gets them off the future Skip list.

 

Thoughts?