A practical checklist for continuous deployment

There is no clever trick in this one, just a handful of decisions worth making deliberately. Run through this the next time continuous deployment comes up.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Doing this properly once is usually cheaper than doing it approximately three times.

The checklist

• Deploying should be boring enough to do on a Friday
• Automate the checks you would otherwise forget
• Small frequent releases are safer than big rare ones
• Someone is named as the owner
• There is a date to review it again

Why it matters

Deploying should be boring enough to do on a Friday. The teams that handle this well are rarely the ones with the biggest budgets. It is the sort of thing that looks like polish right up until it costs you an enquiry.

In practice

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about continuous deployment before you move on:

• Someone can say what the current setup is without going to look
• Automate the checks you would otherwise forget — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.