The real cost of ignoring continuous deployment

Every audit we run turns up some version of this. Nobody bills you for neglecting continuous deployment. The cost shows up somewhere else.

Most development decisions are really maintenance decisions wearing a different hat. Check it against what you would want a competitor's site to get wrong.

Where the cost lands

• Time spent on work that should not have been necessary
• Enquiries that quietly never arrive
• Deploying should be boring enough to do on a Friday
• Rework, once the problem is finally visible

Automate the checks you would otherwise forget. The reasoning matters more than the rule, because the rule has exceptions. Budget a little time for it every quarter and it never becomes a project of its own.

Where to go from here

Small frequent releases are safer than big rare ones. That sounds obvious written down. It is still the thing most often skipped. 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

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
• 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

If you want a second opinion on how yours is set up, ask.