Five mistakes teams make with continuous deployment

We end up explaining this on discovery calls often enough that it deserved writing down. These are the ones we run into repeatedly when we audit continuous deployment.

Most development decisions are really maintenance decisions wearing a different hat. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Warning signs

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Deploying should be boring enough to do on a Friday
• Automate the checks you would otherwise forget
• Never checking whether the fix actually worked

Small frequent releases are safer than big rare ones. The reasoning matters more than the rule, because the rule has exceptions. Check it against what you would want a competitor's site to get wrong.

A reasonable first step

How to tell if yours is fine

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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.