How to get blue-green deployment right
It comes up on almost every project, usually later than it should. The short answer to blue-green deployment is that it is mostly a sequence of small decisions, not one big one.
The bill is a design document: it tells you exactly what your architecture actually does. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
The reason this keeps coming up
Running two environments makes rollback instant. That sounds obvious written down. It is still the thing most often skipped. If it only works because one person remembers to do something, it does not work yet.
The steps
- Establish what you have today before changing anything
- Database changes are what make it complicated
- Practise the rollback before you need it
- Write down the decision so the next person does not re-litigate it
Practise the rollback before you need it. The reasoning matters more than the rule, because the rule has exceptions. Write the reasoning down alongside the decision, because the reasoning is what changes first.
What to do next
How to tell if yours is fine
Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about blue-green deployment before you move on:
- Someone can say what the current setup is without going to look
- Database changes are what make it complicated — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.