Aviation businesses already understand the principle behind DevOps, even where the word is unfamiliar. A flight department does not fly an aircraft by heroics; it flies one by standardised procedures, instrument readings and debriefs. DevOps applies the same discipline to the software that now runs charter booking, parts inventory, crew records and maintenance tracking. This explainer sets out the practice in plain terms, without vendor language, for operators, FBOs and training organisations that buy or build such systems — and for the boards that approve what those organisations spend.
A Working Definition
DevOps describes a way of running software delivery in which the team that creates a system and the team that keeps it alive pursue one set of goals through shared tooling, with feedback both sides can see — the deliberate aim being that changes land with users fast, land safely, and keep landing week after week. Three clarifications prevent most misunderstandings. No vendor can sell it to you. Pinning the word on a job title does not install it either. And it is not a separate department — creating one merely rebuilds the wall the practice exists to remove.
A fourth clarification matters commercially. Because the practice is organisational, its benefits compound quietly: fewer emergency changes, shorter outages, audit evidence produced automatically. None of these appear as line items on a vendor quote, which is partly why the practice is undersold in procurement meetings and overperformed in operations. It also compounds in the labour market: delivery teams with genuine practice retain engineers longer, because calm systems are a retention benefit no benefits package quite matches.
Why Aviation Software Earns No Shortcuts
Operators live with certification logic: an engine is not “probably” airworthy, and a software change should not be “probably” safe. That instinct is correct, but it is frequently aimed at the wrong target. The safer delivery process is not the slower one; it is the one with smaller changes, automated verification and a rehearsed way back. Consider a charter operator’s booking system. A pricing-rule change deployed on its own, verified automatically and reversible within minutes is more auditable than a quarterly bundle of forty changes deployed together, however ceremonially the bundle is signed off.
The Economics, in One Paragraph
Delay has a price that can be computed rather than argued. Take the value a change delivers each week and multiply by however many weeks it sits in a queue; the product is revenue or service the organisation will never recover. A scheduling improvement worth a modest sum each week, held in a quarterly queue, leaks that sum every week it waits — and a queue of a dozen such changes turns caution into a six-figure habit before anyone notices. The defence usually offered is risk reduction, yet the rehearsal evidence points the other way: large, rare, heavily approved changes are the risky ones, and small, frequent, drilled ones are the safe luxury.
The Five Numbers That Describe DevOps Delivery
The DORA research programme supplies the industry-standard measurements, and all five belong on the panel.
- How long a committed change takes to reach live service — the interval your customers experience as responsiveness.
- How frequently releases happen — cadence, which shapes the risk carried by each individual change.
- The recovery interval after a disruption — from detection back to normal service.
- The proportion of releases that cause degradation — the honest error rate of the process.
- The amount of shipped work that must be redone — added to the framework in 2024, and the best early warning that pace is borrowed.
Note the 2023 refinement as well: recovery now counts change-caused failures only, distinguishing self-inflicted incidents from weather, upstream providers and other external events. For a sector that already separates controllable from uncontrollable factors in its safety reporting, the logic will feel familiar — the difference is that here, the controllable factors are nearly all of them.
The Frameworks Behind DevOps Practice
Three references cover most of the theory. CALMS lists Culture, Automation, Lean, Measurement and Sharing as its five ingredients, and remains the quickest test of whether an initiative is whole or merely rebranded automation. The Three Ways describe the flow of work, the feedback loops around it, and the continuous learning that follows. Westrum’s organisational culture model, borrowed from research on safety-critical industries, explains why some shops surface bad news early while others bury it. Foundational texts worth shelf space include Accelerate (2018), the 2021 refresh of The DevOps Handbook, and the continuous-integration essays Martin Fowler published well before the word was fashionable. A precise and free reference for all of these sits at xOps School’s long-form DevOps entry, which is the cleanest starting document for a management discussion.
Controls Auditors Recognise
Regulated operators do not have to choose between pace and evidence. The following controls, all automatable, are standard in mature delivery organisations.
- Least privilege — each person and system holds only the access its work requires.
- Short-lived credentials via OIDC — deployment systems assume temporary identity rather than storing permanent keys.
- Expand-and-contract migrations — database changes are added in a backward-compatible shape, and the old shape is retired only once the new code is entirely live, so a reversal never strands data.
- Quarterly audit sampling — roughly ten random changes per quarter are traced from request to production, generating evidence continuously instead of annually.
- Break-glass signals — emergency merges alert automatically, so exceptions are visible rather than quietly absorbed.
Questions to Ask at the Next Software Review
For boards and owners who buy rather than build, the practice converts into a short question sheet. Ask the vendor or internal team to walk through the last three changes: how long each took from approval to live, whether any caused degradation, and how long recovery took when one did. Ask to see the rollback steps, and when they were last executed. Ask how access is granted when an engineer joins and removed when one leaves. Complete, prompt answers indicate a mature operation; hesitation on the recovery question is the one that should pause a signature. None of this requires the asker to read code. It requires only the insistence that delivery claims arrive with delivery numbers, which is the standard aviation applies to every other performance claim it hears.
What DevOps Is Not
A brief caution list closes the explainer. A permanent “DevOps team” is an anti-pattern; adoption succeeds through coached pilots — the published scoring gives a coached pilot 4.25 of 5 and a top-down mandate just 2.50. More approvals after an incident is another anti-pattern — heavyweight change boards correlate with worse performance in the research, not better. Long-lived branches, big-bang programmes and metrics used as leaderboards complete the set. Each of these fails the same way: it substitutes a visible ritual for the invisible discipline the ritual was meant to imitate. A useful smell test runs the other direction: ask what the team would do differently tomorrow if a metric moved unexpectedly. Teams with an answer are practising; teams without one are performing.
The reliability discipline adjacent to all this is covered further in this look at the skills behind reliable engineering; readers wanting the systems parallel will find how a flight management system works a useful mental model, as will this beginner’s guide to radar systems for the value of continuous sensing.
The summary for an aviation board is one sentence long: treat software delivery the way you treat flight operations — measured, rehearsed, debriefed without blame — and both the pace and the audit trail improve together. The alternative — buying the word without the practice — has been tried often enough that its outcome is also part of the record.
