Nobody at a flying club flies on memory. Every manoeuvre gets a logbook entry, and no entry goes far without an instructor’s signature — the smallest document in aviation, carrying the most weight. I think about that whenever a software team tells me their scheduling tool updated itself overnight, changed what every student saw, and left nobody’s name attached to the decision. Aviation would never sign off a checkride that way. The practice that brings the same discipline to shipping software is called ReleaseOps — an informal label from The Ops Atlas for the territory that lies between release engineering, which builds and verifies, and release management, which governs the calendar. Its first rule fits on a logbook line: installing a version and exposing its behaviour to users are two separate acts, and each deserves its own signature.
ReleaseOps, read like a logbook
Open the entry and it reads like a career document, not a buzzword. Release engineering is the maintenance shop: it builds the artefact, runs the checks, and hands back something airworthy. Release management is the training calendar: it governs slots, approvals, and who may fly when. ReleaseOps is the strategy written between those two pages — the plan deciding which users meet a change first, and the route back when the weather turns. The vocabulary is blunt. A deploy puts a version on a machine; the software runs, but users may notice nothing. A release exposes behaviour to real people. Tie the two together — one switch that installs, exposes, and announces at once — and every launch becomes a coin flip shown to your whole audience. Keep them separate and a launch turns into a sequence of small, reversible decisions.
Skill one: flying the two dials
Practitioners describe the whole game with two dials. The first dial sets where each version runs. The second decides which people get to watch it behave. A feature flag moves the exposure dial alone — the code is already aboard, merely hidden. A canary or a blue-green switch moves both at once, putting a new version on a slice of traffic. Students of flying will recognise the split: filing a flight plan is not the same as boarding passengers. You file, you position, and only then do you open the door. Teams that never learned this distinction release the way a student soloing for the first time would carry a full load of passengers — technically airborne, entirely unprepared for what one surprise does to everyone aboard.
Choosing the mechanism is part of the same skill, because each has its own stall speed. A rolling update mixes old and new versions on one fleet, so both behaviours mingle in your metrics and backing out takes minutes, not seconds. A blue-green pair flips between environments in moments but asks you to pay for double capacity, and any database underneath must speak to both versions at once. Rings and waves buy baking time by promoting through groups — internal staff first, then the cautious public tiers. Pick per change, not per company: a slow-moving internal tool and a booking desk that lives on search traffic deserve different exposure plans.
Skill two: keeping the abort right close
Aviation is strict about final authority. One pilot is pilot in command; in an emergency, nobody debates. Good release practice keeps the same clarity on call: the engineer holding the pager holds an unconditional right to abort — pull the version, close the exposure, no committee required. The quieter half of the rule matters more. Anyone who can merge code to the main branch effectively holds release rights too, if your pipeline tags and ships whatever lands there. Authority to change the software is authority over the release, whether the org chart admits it or not. Log who can actually move the software, and you will find the list is longer than the one on the release policy page. The fix is not more paperwork; it is making the exposure controls so ordinary that flipping them back takes less courage than a landing in crosswind.
Skill three: letting evidence hold the pen
The signature culture has a failure mode: committees. People who never flew with you start signing your logbook, queues form, and risk hides in the delay itself. The research verdict here is refreshingly blunt — DORA examined external change approval boards and found no evidence they lower change failure rates. What correlates with safer delivery is plainer: a colleague who actually reviewed the change, plus automated evidence — tests, checks, staged metrics recorded while the change is in the air. The aviation parallel is exact: a dual check with the instructor in the seat beats a stack of forms signed in an office. Build your sign-off from evidence machines, not from meeting calendars, and keep every override attached to a named person with an expiry date — a signature that never expires is not a signature, it is a rubber stamp.
Skill four: logging the numbers crews feel
A logbook is worthless if it records the wrong columns. Four measures belong in a release log:
- Release lead time — how long a merged change takes to reach full exposure. Long values usually mean the exposure dial and the approval process are tangled together.
- Time to safe state — when something misbehaves, how many minutes until users are out of the blast radius. This number, not the deploy count, is what your users experience.
- Exposure per bad release — the user-minutes a faulty build accumulates before anyone stops it. Staged rollouts exist to shrink this figure; a big-bang launch maximises it by design.
- False-abort rate — how often you pull a version that was actually fine. Too high, and crews stop trusting the alarms that matter.
Start crude and honest: a shared note per launch, timestamps for merge, first exposure, full exposure, and any pull-back. After a quarter of entries you will see the pattern instructors see in a student’s logbook — which manoeuvres are safe, which are performed only in good weather, and which are being signed off without ever being practised.
A ReleaseOps logbook entry worth keeping
If you are training toward the flight deck, the tools around you — scheduling, exam prep, dispatch — are shipped by teams making these calls, and the hiring managers for those teams read resumes the way instructors read logbooks: for evidence of judgement under change. If you are still choosing your route, the aviation entrance exam guide and this walkthrough on preparing for pilot aptitude tests cover the earlier legs of the journey. Technically minded readers who prefer the software side of an airfield can start with this practical guide to learning site reliability engineering, then extend it with the ReleaseOps entry in The Ops Atlas, which documents the practices above in one place.
The entry, condensed: two acts, two dials, one named abort authority, evidence over committees, four honest numbers. Review it the way a chief instructor reviews a student file before recommending a checkride — not to add ceremony, but to confirm that what was logged was actually flown. That habit, repeated across a career, is what separates pilots who pass checks from pilots who stay safe; software teams earn the same split the same way.
