Getting started with continuous deployment
We end up explaining this on discovery calls often enough that it deserved writing down. A short on-ramp to continuous deployment for teams who have not touched it before.
The question is rarely whether something can be built, but what it costs to keep running afterwards. Write the reasoning down alongside the decision, because the reasoning is what changes first.
The reason this keeps coming up
Deploying should be boring enough to do on a Friday. The cost of getting this wrong is rarely visible on the day it happens. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Your first week
- Find out what is already in place
- Automate the checks you would otherwise forget
- Change one thing and measure it
Small frequent releases are safer than big rare ones. The reasoning matters more than the rule, because the rule has exceptions. If it only works because one person remembers to do something, it does not work yet.
How to tell if yours is fine
Most development decisions are really maintenance decisions wearing a different hat. 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
If any of that sounds like a description of your current setup, it is fixable.