A release is a decision, not only an action
A release plan usually describes the deployment itself: the checklist, the window, the people on the call. The step that gets the least attention is the one that decides how the day goes when something is wrong, which is going back.
Releases tend to go wrong at the edges: a system owned by someone else, or a dependency that behaves differently from the test environment. That is why I link the release plan to the dependency and integration work from early in the project, not only in the last week.
On one release we did a rollback. The ERP offered a different API and its performance was poor. I will not retell the details here, because what matters is why it was a decision and not a crisis.
What makes a rollback a controlled decision
A rollback plan agreed in advance turns a stressful judgement into a check against criteria that everyone already accepted. Nobody has to argue, in the middle of the window, about whether going back is a failure. It is one of the planned outcomes. I try to agree four things:
- The triggers. What we measure and the threshold that means going back, for example response time on a key integration.
- The owner. One named person who makes the call, and the time by which the call must be made.
- The way back. How the previous version and its data are restored, and proof that someone has actually tried it.
- The message. Who tells the client's business users and stakeholders, and in what words, before anyone has to ask.
I write the plan into the release checklist, next to the steps going forward, so that everyone on the call reads the same page. A plan that lives in one person's head will not survive a long evening.
Mobile releases do not roll back
I have also handled releases to the mobile stores, for a self-service app used by insurance customers. A store release is a different kind of release. Once customers have installed a version you cannot pull it back from their phones. You ship a fix forward, and the store review adds time that you do not control.
So the care moves to what happens before release: thorough testing, a staged rollout where the stores allow it, and a plan for the forward fix that is ready before it is needed.
Store listings, release notes and screenshots also need an owner and a date, because they can hold up a release for reasons that have nothing to do with the code.
Protecting the milestone
Production go-live is the last billing milestone in my projects, so there is always pressure to declare success on the day. An honest rollback plan protects that milestone rather than delaying it. A rollback with a date for the retry is a better conversation with the client than a go-live that is quietly bad.
It is also the no surprises principle in practice. The client hears about the possibility of going back before the day, so when it happens it is the plan working, not the plan failing.