· 4 min read · Engineering Craft
Keeping Production Boring: Migrations, Rollbacks, and Small Releases
Excitement in production is a cost center. The craft is making change so routine that nobody has to be a hero.
Ship small, make every migration reversible, and rehearse the rollback before you need it. Boring releases are a design achievement, not a lack of ambition.
Small releases are a safety feature
A release with four changes can be bisected by reading the commit list. A release with four hundred changes can be bisected by taking annual leave. Batch size is the single strongest lever on incident size, and it costs nothing but the discipline to ship what is ready instead of waiting for what is not.
Feature flags complete the trick: deploy the code dark, enable it for yourselves, then a slice of users, then everyone. Deployment and release become separate decisions, and a bad idea stops being an emergency redeploy.
Every migration needs a way back
Before a schema change ships, write the down migration and test it on a restored copy of real-shaped data. Not because you expect to use it, but because writing it forces the question nobody asks during the happy path: what exactly did we just destroy, and can we get it back?
The expand-and-contract rhythm keeps this cheap. Add before you remove, overlap before you cut over, and let a full release pass between the two halves. Future you, mid-incident, will be grateful for the patience.
“Heroics in production are a sign that the system needed a hero. Build the system that does not.”
Boring is the compliment
Users never see this work, which is the point. They see a product that changes steadily and breaks rarely, maintained by a team that sleeps normally. In my experience that is what ten years of engineering judgment mostly adds up to: fewer surprises, chosen on purpose, in advance.