How to get continuous deployment right
This is cheap to get right at the start and expensive to retrofit. The short answer to continuous deployment is that it is mostly a sequence of small decisions, not one big one.
The question is rarely whether something can be built, but what it costs to keep running afterwards. The version that survives contact with a real deadline is the simple one.
Why this earns attention
Deploying should be boring enough to do on a Friday. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
The steps
- Establish what you have today before changing anything
- Automate the checks you would otherwise forget
- Small frequent releases are safer than big rare ones
- Write down the decision so the next person does not re-litigate it
Small frequent releases are safer than big rare ones. The cost of getting this wrong is rarely visible on the day it happens. Assume whoever inherits this will have half your context and none of your patience.
Turning this into a decision
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
- 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
None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.