A release manager exists because deploying is risky. The role does not reduce the risk; it concentrates the coordination cost in one person so that everyone else can ignore it. That is a rational response to a real problem, and it is also a signal about what needs fixing.
The three things that make deploys risky
- Batch size. A release containing forty changes has forty suspects when something breaks.
- Irreversibility. If rollback means a database restore, nobody will authorise it under pressure.
- Invisibility. If you cannot see failure within minutes, you cannot respond within minutes.
Every one of those is technical. None is solved by a person with a spreadsheet, though a person with a spreadsheet can hold the situation together for years — which is precisely why the underlying problems persist.
Reversibility first
We start with rollback rather than batch size, because reversibility is what makes small batches safe to attempt. Feature flags decouple deployment from release: the code goes out dark, and turning it on is a configuration change with an instant undo.
Schema changes need the same treatment: expand, migrate, contract. Add the new column, write to both, backfill, switch reads, and only then drop the old one. Each step is individually reversible, which is what makes the sequence safe.
Then make the batches small
Once rollback is genuinely one click, deploying ten times a day becomes less frightening than deploying once a fortnight. Each deploy carries one change, so when a metric moves, the cause is unambiguous.
The change advisory board does not have to go
In regulated environments this is where the objection lands. It rarely holds. The board's legitimate interest is that changes are reviewed, evidenced and reversible — all of which a well-instrumented pipeline demonstrates better than a fortnightly meeting.
We have taken this approach through financial-services change control several times. The board stays; what changes is that its evidence is generated automatically, and its approval gates the flag rather than the deploy.
Deployment frequency
Typical after two quarters
Lower change failure rate
Smaller batches, faster detection
- delivery
- devops
- platform
Author
Dana Whitfield
Principal Engineer
Fifteen years in payments and platform engineering. Writes about the operational side of delivery.
Meet the team