Aviation worked out the difference between ready and released a long time ago. An aircraft can be signed off, fuelled, and holding short — none of that means the flight has been released. Dispatch still makes a decision, on the evidence in front of it, about whether this aeroplane meets the requirements to carry passengers now. Software teams keep rediscovering that distinction the hard way, and ReleaseOps is the label the Ops Atlas pins on the discipline of running releases that way: installing a version is one act, exposing behaviour to users is another, and keeping them separate is what turns a launch from a coin toss into a decision. Along the way the practice has collected a set of beliefs that sound like airmanship but do not survive contact with the record. Five of them are due for a checkride.
Myth: a deploy and a release are the same entry in the log
The conviction underneath this one is that once the new build is running in production, the job is finished and the announcement is a formality. It is not. Coupling the install, the exposure, and the announcement together makes every change all-or-nothing: if the new behaviour is wrong, the only lever available is unwinding the whole bundle. The working model separates two dials — one deciding which build runs on which machines, the other deciding which users meet the new behaviour — and the point of the split is that each dial can be turned, measured, and turned back on its own. A pilot who understands a career built on staged privileges — solo, then dual-checked, then type-rated — already grasps the shape of it: capability first, exposure gradually, each step reversible.
Myth: the blue-green switch is free insurance
Blue-green looks like the closest thing software has to a go-around: keep the old version warm, cut traffic across, cut it back if anything smells wrong. Two costs hide under that comfort. The first is arithmetic — two full environments running means paying double capacity for the privilege. The second is subtler and more dangerous: unless the database schema suits both versions at once, a blue-green flip is not a controlled experiment at all, because both colours of traffic hit the same data store. With no traffic split between old and new, the technique degenerates into a before-and-after observation with no comparison group — which is precisely the thing a careful operator refuses to call evidence. The honest reading is that blue-green buys speed of reversal in seconds, and pays for it with capacity and with a schema discipline many teams have never actually practised.
Myth: one percent for an hour proves a canary
This is the myth with the hardest numbers behind its correction. Suppose a change doubles a rare error rate — from two failures in a thousand to four. To catch that doubling with eighty percent confidence while keeping false alarms to five percent, a canary needs roughly four thousand requests. At one percent of traffic on a service doing fifty requests a second, that sample takes over two hours to accumulate; the same sample at ten percent arrives in about thirteen minutes. The ceremonial canary — a few minutes of one-percent traffic on a sleepy service — surfaces only faults already running at ten times the baseline — the ones nobody needed a canary to notice.
There is a second trap in the same arithmetic. Teams set the alarm at the effect size they hope to detect, rather than at the critical value the statistics demand — a threshold around zero point one two percentage points in the worked example above. Set it at the effect itself, and a true doubling gets caught roughly half the time, which is a coin flip dressed up as a gate. Anyone who has weighed salary outcomes against training cost knows the difference between a number that feels right and a number that has been worked: sample size is the same kind of calculation, just with traffic instead of money.
Myth: behind a flag, nothing has really shipped
Feature flags are the cleanest expression of the exposure dial, and they earn their keep — flipping a flag off takes seconds. But the belief that a flagged change is not yet a release is where teams get hurt. Every behaviour change is a release, whether it travels as code, configuration, content, or policy data, because every one of those can alter what users experience the moment it is exposed. Flags bring their own debt on top: release flags that never expire, combinations of flags nobody has ever tested together, and the quiet accumulation of paths that only exist in production. The discipline that works is a registry with expiry dates — release flags should live for weeks, not seasons — and a rehearsal of flag-off as a real back-out lever, because a flag only helps when the defect lives inside the flagged path.
Myth: a longer freeze is a safer season
Freezes feel like weather minimums: when conditions are bad, you do not launch. The evidence is less flattering. DORA’s researchers went looking for proof that outside approval boards reduce how often changes fail and came back empty-handed; the same body of guidance steers teams away from the routine code freeze. The freezes that earn their place are narrower: change freezes around genuine high-stakes windows, time-window blockers for specific events, and the error-budget freeze, where a service that has spent its reliability budget halts everything except priority-zero and security fixes until the budget recovers. That last one is the most aviation-minded of the lot — it is a hard minimum, not a mood. Note also the distinction the sheets make between blocking, pausing, and merely recording at a gate, and any override must bear an owner’s name plus a date when it dies; and remember that on-call always holds the abort right, because anyone who can merge to main already holds release power in practice.
What ReleaseOps keeps from aviation anyway
The exchange is not entirely one-directional; the software side has habits worth importing back. Back-out levers in a strict priority order — kill the flag first, abort or roll back second, and only then roll forward along the staged route — mirror the way a quick-reference handbook orders memory items. The rule that a rollback never survives new data formats without expand-and-contract planning is the data-layer equivalent of knowing which failures a checklist actually covers. And the metric set is refreshingly unglamorous: early-detection ratio, user-minutes of exposure per bad release, time to safe state, false-abort rate, and overdue flag count. None of them flatter a dashboard; all of them describe whether the release process can be trusted on a bad day. The cautionary cases in the field — a reused flag on an undeployed server, an unstaged content configuration crashing hosts fleet-wide, a quota feature triggered globally by replicated policy data — all share one shape: an exposure nobody had listed as a release.
A ReleaseOps walk-around before the next launch
Run it like a pre-flight. Confirm the deploy and the release have separate levers, and that the announcement is a third decision rather than a fuse. Check that the rollback has been practised, because one nobody has drilled is just optimism wearing a button, and that the schema will tolerate both versions during any flip. Size the canary against actual traffic, and set the alarm at the critical value the maths demands. Give every flag an expiry date and audit the combinations. Then let the maturity ladder do its quiet work, the ad-hoc start, then repeatable, then decoupled, then progressive delivery — one service at a time. Teams that want a structured starting point can do worse than the first-ninety-days plan: a release policy and flag registry in the first month, dark deploys and rehearsed rollbacks in the second, automated canary analysis on three services in the third. By then the five myths above read like what they always were — the pre-flight inspection items nobody checks twice, until the day the investment is on the line and the process has to hold.
