Every flying school has that one student who asks the question everyone else was too polite to ask. This post is for them — and for the folks who build and mind the software those students depend on. ReleaseOps keeps coming up in aviation circles lately, and the questions that reach our inbox are refreshingly down to earth. So here are seven of them, answered the way we’d answer across the flight desk: no jargon walls, no vendor pitch, just the ideas and a few numbers that make them stick.
What does ReleaseOps actually mean?
It is shorthand for the craft of deciding how software reaches people — an informal label that The Ops Atlas uses for the territory between release engineering (building and verifying the thing) and release management (governing when and for whom). The whole practice hangs on one distinction. A deploy puts a version onto machines; it runs, hums, and bothers nobody. A release is the moment its behaviour becomes visible to users. Schools know this difference instinctively: parking a new simulator in the building is not the same as putting students in it. Confuse the two and every update turns into a surprise for your whole intake at once.
Is scheduling a change the same as releasing it?
No, and this is the distinction worth tattooing somewhere visible. You can put a lesson on next month’s calendar without flying it; the date is a plan, not the lesson. Software works identically. Installing a version is the plan; exposing its behaviour is the lesson happening. Teams that bundle installation, exposure, and the announcement into a single motion — and plenty still do — lose the ability to pause between them. Keep the steps apart and you gain something precious: the option to install quietly on a Tuesday, show the change to a handful of friendly users on Wednesday, measure what those users experienced, and only announce on Thursday once the graph looks friendly too. Measurement is what makes the pause between stages worth having.
We tested everything. Why not show it to all users at once?
Because tests examine the software, and exposure examines the fit. Real traffic carries habits no test suite imagines — odd browsers, unusual hours, the student who books lessons at 3 a.m. from a phone with three percent battery. Staging does not replace testing; it complements it, which is exactly how the research literature frames the relationship. Think of a long journey handled in legs instead of one brutal overnight drive — that is the logic behind planning a road trip in comfortable stages, and it is the logic behind rings and waves: staff first, then a small public slice, then everyone, with a pause at each border to check the instruments.
How big should the first slice be?
Bigger than a token sliver, smaller than a gamble — and the honest answer comes from arithmetic, not vibes. Picture a booking service handling fifty requests a second, with errors quietly doubling from two per thousand to four. To catch that doubling eight times out of ten, while tolerating false alarms five percent of the time, a canary needs roughly four thousand requests. Spread across one percent of traffic, that means a couple of hours of baking before judgement; hand the canary ten percent and thirteen minutes will do. A quiet service with thin traffic has to accept longer waits or wider slices — there is no way to shortcut the sample. One more subtlety trips people up: set the alarm at the threshold that actually separates the two error rates — about 0.12 points in our worked case — and not at the result you are hoping to witness. Set the alarm at the wrong altitude and a genuine doubling sails past you roughly half the time.
Is flipping a feature flag a release?
Yes — treat every behaviour change as a release and you will stop being surprised by them. A flag leaves the code deployed and simply gates who sees it, which makes it the purest exposure control there is: seconds to turn, seconds to reverse. But flags carry luggage. Old ones linger for years until nobody remembers what they guard, combinations ship untested, and someone eventually flips a switch that a former colleague left pointing at a reused block of logic. Now add the quiet cousin: configuration and policy data. Changing them alters behaviour just as surely as code does, so they deserve the same staging and the same scrutiny. Pruning stale flags is housekeeping in the same spirit as stopping small financial leaks before they drain the account — individually tiny, collectively expensive.
Who is allowed to hit the stop button?
Whoever is on call, whenever they judge it necessary — the right to abort belongs to the person watching the screens, unconditionally and without a meeting. Two useful corollaries follow. First, anyone who can merge code into the main branch is also a release decision-maker in practice, because whatever lands there tends to ship. Second, giving one named person the final call is not a power grab; it is the same reason a cockpit has a pilot in command. The Ops Atlas page on ReleaseOps calls this the abort right, and it is the single most calming habit a team can adopt.
So does a small school team really need ReleaseOps?
Scale it to your size and breathe. The test is simple: do you operate the software yourself, do you ship often, and do you have enough traffic to compare behaviour between groups? Three yeses and the discipline pays for itself. A quiet internal tool with a handful of users needs far less — a calendar of changes and a rollback plan you have actually rehearsed, not just believed in. Heavy process on a two-person team is exactly like travelling your own way: the point is choosing the pace that fits the journey, not copying someone else’s itinerary. So start small, this month, without a big programme. Keep a simple registry of live flags with owners and expiry dates; release flags are meant to retire within weeks, not collect dust. Rehearse one rollback until it is boring. Write down what counts as a release at your school — including that “harmless” settings change. None of this needs new headcount, and each step shortens the distance between a mistake and its undo.
If the whole FAQ has to shrink to a single line, keep this one: installing is not exposing, and every habit above exists to hold a wide, visible, controllable gap between the two — a gap you open on purpose and close on your own schedule.
