Deutsch
Everyone designs the upgrade path; few design the rollback path in advance — especially the database schema. Notes from the release that taught me.essay · standmeet2026.10.15 · essay
2026.10.15·3 min lesen#essay#operations

Design the Way Back

Everyone designs the upgrade path; few design the rollback path in advance — especially the database schema. Notes from the release that taught me.

Every release gets a tag. A release is a fixed point in the history, not a moving branch. That part is basic discipline, and most teams have it.

The part most teams skip is the return trip.

Everyone designs the upgrade path. If a rollback is possible — and on any system that matters, it must be — then the rollback path has to be designed too, at the same time, with the same care. Especially the database schema. A migration that only goes one way is a trap you set for yourself and discover on the worst possible morning.

I learned this from a release of my own, v0.1.33, in September 2026. The build leaked my backend URL into the app. The app then proxied its own calls back to itself, and users got errors everywhere while every health check said the system was fine.

The worst part was not the bug. The upgrade button inside the product ran over that same proxy — so the normal repair path was broken by the same failure it was supposed to repair. And underneath, the updater had been following the latest tag while the compose file pinned another version: what was running had quietly drifted from what was declared.

The recovery came through the hosting layer, around the app, not through it. I changed the image tags, redeployed, and watched the old build answer again.

Three rules came out of that morning, and a later one — v0.1.151 crash-looping on a migration-ordering mistake — underlined them.

Pin everything. Nothing follows "latest".

A bad release must not be able to block its own rollback. The way back has to be independent of the thing being rolled back, and it has to be tested, not assumed.

And keep distribution decentralized. Do not push a new version into everyone's machine in one motion. Clients pull the version they run; a team can pin itself where it is. Roll out to a small slice first, where the infrastructure allows it. Then there is never a single moment where everybody changes at once — and a bad version is something a few people step back from, not something everybody wakes up inside.

When the way back is designed in advance, the first hour of a bad release is not a rescue. It is a procedure.

fragen Sie die KI über diesen essay·kontext: "design the way back"
›