Rule 20 of 38 · Chapter III — Make Failure Visible
Make rollbacks boring
Why this rule exists
The ability to undo a deployment quickly is what lets you move fast safely. When rollback is a tense, manual, rarely-rehearsed procedure, people hesitate to ship and hesitate again to revert when something is wrong — and that hesitation, in the middle of an incident, is where small problems become outages. A boring rollback is a fast, obvious decision instead of a gamble.
In practice
Keep releases backward-compatible so the previous version can run against the current data. Decouple schema migrations from code deploys and make them additive first, destructive later. Make rollback a single well-worn command, and actually practice it, so reverting is never the first time you've tried. Guard risky changes behind flags you can flip without redeploying.
When it doesn't apply
Some changes genuinely cannot be rolled back — a destructive migration, an irreversible external side effect. For those, invest instead in forward fixes, staged rollout, and stronger pre-release verification, and be explicit that rollback is off the table.