Should you upgrade lower or higher environment first and why

There is one issue with upgrades. You cannot deploy from a higher version to a lower. In case you upgrade the lower first, you stop the development process until the higher one is upgraded as well.

Our clients typically have 3-4 environments. We start in the middle to find any issues, then higher first, lower last to keep the option for hot fixes.

Hi Stefan,

Considering we aren't making any new changes to push from a lower environment (Higher Version) to higher environment (Lower Version), what else can be the challenge in updating the lower environment to a higher version before updating the higher environment, any other challenges you can think of?

Besides the normal practice of smoke testing and plugin version checking, I do not see any challenge.

The system I run is a 3-environment setup: Dev, TEST, and Production.

Our deployment structure is slightly unusual though: once deployments are tested in TEST, they're typically deployed to Production straight from Dev.  Since it's mostly only me (plus one other junior dev with me now), there are very little chances for overlapping or conflicting changes to crop up.  We deploy individual tickets as they're completed via their own app packages.

When a new version rolls out I like to try it out right away.  The upgrade strategy I've adopted and have had no issues with over the bulk of the prior 2 1/2 years is about like this:  As soon as we're eligible, I schedule TEST to be upgraded as soon as possible.  Then I and the other business owners / stakeholders will try out the new features and check for stability, etc... and once we're sure there are no blockers created, I schedule Dev and Production to be upgraded around the same time during a forthcoming weekend timeslot (they only like doing production instance upgrades during the weekends).  This prevents us from ever being unable to deploy to production when needed.

My clients usually have 4 environments.

Typical flow is Test -> Staging -> Production -> Development

We usually run test regressions for a couple of days in the test environment. Once that is done we do Staging and Production in very short order. Finally we update development last.

Another possible flow is to do Dev & Test together. That leaves you with Staging and Production on a lower version to deploy hotfixes. Any hotfixes done while waiting for the upgrade can be retrofitted back in dev. Once your regressions are done, you can upgrade Staging and Production close together.

The advantage of the 2nd approach is that the compare and deploy will not break between dev & test while you're waiting on the upgrade.

Really depends on your priorities.

About the only issue I could see, it turns out is about the only issue mentioned by anyone else here, which is good.  That issue is, if Dev is at a higher version than Prod, then you can't be certain Prod will run everything that comes out of Dev.  If Dev has been upgraded, Prod will have to be upgraded before any development can go from Dev to Prod.  So if Prod does get upgraded last, it has to be very soon after, because the upgrade becomes a blocker for all development.

Also, if you do see any aberrant behavior when you upgrade, it's not going to have the impact on lower environments that it would have on Production.  The key thing I would be looking out for is Removals.  Those could play havoc with your apps.  Since you don't want end users to see everything suddenly broken, Prod probably shouldn't be the very first.

So Prod can't be first, and might not want to be last, that puts it in the middle.  Dev is OK being last, so that leaves Test first.  If you only had Dev and Prod, I'd say not wanting to see everything broken would trump dev being blocked.  In that case, I'd say Dev and then Prod a week later.  But again, what are you doing without a Test environment?  Get a Test environment! 

Higher env should always go first. You never know when you might have to fix and deploy something from lower to higher.