How will we notice it’s going wrong?
A successful deployment step only tells you the software was shipped. Whether the important processes still work is something we have to check separately. So we decide beforehand which signals and business checks count after the release.
Who watches the rollout? Who decides whether to stop it? And who can be reached if a problem only shows up later? Those questions are better asked before the date than during the first outage.
The old version alone isn’t always enough.
Switching the application back can fail if the new version has already stored data differently or changed an interface. That’s why we look at code, data and dependencies together. “The old image is still there” isn’t a complete way back.
Depending on the change, preparatory steps can help: a data format that stays compatible at first, a feature that can be switched separately, or a migration in several stages. Which one fits depends on the system. Not every change is easy to reverse.
Roll out smaller. Look closer.
Where the application allows it, we release in stages and check the effects before more users are affected. That includes a tested procedure for pausing or switching back, with clear responsibilities.
Restoring from a backup has consequences too: how long does it take, and which later changes to the data will be missing afterwards? Limits like these belong in the plan, where people will see them, rather than in a footnote nobody finds when it counts.
And what about Friday?
The day of the week is only part of the decision. What counts is the change, how well it can be checked, the way back and the people available to watch over operations. Without those, a Monday doesn’t automatically become a good date.
A sensible release plan can be explained and rehearsed. Then nobody involved has to keep their fingers crossed and clutch the phone at the same time.
Sound familiar?
Tell us about it