Release Process
How a change reaches a live system, and how the order keeps failures in the cheap column.
Overview
A release process is mostly a set of gates arranged so that when something fails, it fails while the previous version is still serving. This document covers the migration posture that makes that possible, the deployment sequence and why the order is what it is, and the two rollback paths with their very different costs.
Why This Exists
Every rule here exists to keep a bad release in one column of a two-column table. Restarting the previous image costs about a minute and loses nothing. Restoring a backup costs an hour or more and loses everything since the dump was taken. That gap is the whole subject. A schema change that the previous build cannot run against has silently moved a future failure from the first column to the second, and it did so at the moment someone deleted a line from a schema file, not at the moment the release broke.
The facts a release process is derived from
The default posture is additive
Expand, migrate, contract, and the real reason for it
Not every table deserves the same ceremony
The deployment sequence, and why the order is what it is
Two rollbacks, and their very different costs
Downtime is a budget, not a taboo
What this deliberately does not recommend
Related Principles· 2
Related Documents· 5
Referenced By· 11
Version History
- v0.1.0
Initial structure and metadata established.
- v0.2.0
Written from real experience. Covers the architectural facts the process derives from, the additive posture, expand/migrate/contract with the rollback justification rather than the mixed-traffic one, the deployment sequence with a reason per step, the two rollback paths, downtime as a budget, and what is deliberately not recommended.