step 10 / 32 · 6 min
Deploying is not releasing
Friday, 4pm. A team deploys a change that had been waiting three weeks. It contains work from four people. Something breaks, and because four changes went out together nobody can say which one did it.
They roll back all four, losing three weeks of finished work, and spend Monday finding out which one was at fault.
Two things that sound the same
- Deploy: the code is now on the servers.
- Release: users can now see it.
Treating them as one event is what makes the Friday above frightening. Separate them and most of the fear goes away.
A feature flag is how: ship the code switched off, turn it on for yourself, then for 1%, then for everyone. If it misbehaves, turn it off. That is a configuration change, not a deploy, and it takes seconds.
Why deploying more often is safer
It sounds backwards and it is not. A deploy containing one change has one suspect. Twenty changes have twenty.
| Deploys | Changes each | If it breaks |
|---|---|---|
| once a month | 40 | a day of bisecting |
| once a day | 2 | look at two things |
| on every merge | 1 | you already know |
The risk is in the batch size, not the frequency.
What a pipeline is for
On every push: build, run the tests, and refuse to go further if either fails. That is continuous integration, and its value is that a broken main branch is discovered in minutes by the person who broke it, rather than in three weeks by somebody else.
Before you deploy
Know how you would undo it. A rollback that has never been tried is a plan you are hoping about, and the moment you need it is the moment you have least time to work it out.
Database migrations are the sharp edge here: code can usually be rolled back and a dropped column cannot, which is why migrations are written so the old code still works against the new schema.