Blue-green deployment, explained without the jargon

We end up explaining this on discovery calls often enough that it deserved writing down. Here is blue-green deployment without the vocabulary that usually surrounds it.

Operability is a feature, and it has to be built rather than bought. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

The short version

Running two environments makes rollback instant. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. Getting it slightly wrong is survivable. Ignoring it entirely is not.

Database changes are what make it complicated. It is worth being explicit about, because assumptions differ quietly. The version that survives contact with a real deadline is the simple one.

Where to go from here

Practise the rollback before you need it. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What this looks like day to day

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
• Running two environments makes rollback instant — 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.