When continuous deployment is worth the effort

Most teams know this matters. Fewer have decided who owns it. Continuous deployment is not free, and pretending otherwise leads to bad decisions.

Most development decisions are really maintenance decisions wearing a different hat. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

When it is worth it

Deploying should be boring enough to do on a Friday. The cost of getting this wrong is rarely visible on the day it happens. If two people in the business would answer this differently, that gap is the actual problem.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. Getting it slightly wrong is survivable. Ignoring it entirely is not.

How to decide

Small frequent releases are safer than big rare ones. This is the sort of thing that compounds, quietly, in both directions. If it only works because one person remembers to do something, it does not work yet.

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
• Deploying should be boring enough to do on a Friday — 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.