Continuous deployment, explained without the jargon

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

Most development decisions are really maintenance decisions wearing a different hat. It rarely shows up as a line item, which is exactly why it slips.

The short version

Deploying should be boring enough to do on a Friday. That sounds obvious written down. It is still the thing most often skipped. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. None of that requires a large budget, only a decision and someone to own it.

Automate the checks you would otherwise forget. In practice this is a scheduling problem more than a technical one. Check it against what you would want a competitor's site to get wrong.

A reasonable first step

Small frequent releases are safer than big rare ones. There is a version of this that is over-engineered, and it is worth avoiding. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

The short version

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about continuous deployment before you move on:

• Someone can say what the current setup is without going to look
• Small frequent releases are safer than big rare ones — 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.