Before an aircraft pushes back, someone works through a list, item by item, and signs it. Nothing on that list is optional, nothing depends on mood, and nothing is skipped because the schedule is tight. Aviation software deserves the same discipline, and DevOps supplies it. The audit below has fifteen items across five sections; score each one pass, partial or fail, and you will know exactly where your release pipeline is airworthy and where it is not.
Why DevOps discipline suits flight-ops software
A booking engine, a crew-rostering tool and a departure-control system share one property: failures are public, expensive and timestamped. The practices that aviation hardware already lives by — small inspected increments, checklists, rehearsed emergencies — translate almost untouched. The research field that grew around this translation is substantial; for the full background, the Ops Atlas DevOps guide assembles the metrics, frameworks and history in one reference.
How to run the audit properly
Assign one engineer and one operations lead per section, and demand evidence rather than assurances: a link to the board, the timestamp of the last rollback drill, the audit sampling sheet. A checklist answered from memory is a brochure. Time budget: half a day for the full fifteen items, and the honest result usually contains four to seven partials. That is normal, and it is a work queue, not an indictment.
Section one: flow checks
- Has the value stream been mapped within the last year, with waiting times measured rather than estimated?
- Do branches live less than two days, with trunk-based development the documented default?
- Is there exactly one automated build per change, promoted unchanged through every environment?
- Does deployment frequency suit the risk — small releases several times a week, not a seasonal big bang?
Failing items here usually trace to queues: a merge window, a shared test environment, a release train that leaves when it pleases. Flow problems are scheduling problems wearing a technical costume, and they carry a measurable fare. Put a number on the waiting: an improvement to the booking flow worth 5,000 weekly that idles three weeks forfeits 15,000, and a dozen similar stalls across a quarter erase 180,000. No route-planning meeting would shrug at that figure; a release calendar should not either.
Section two: feedback checks
- Does any commit receive build-and-test feedback in roughly ten minutes or less?
- Are the five delivery metrics published where the team can see them — flow time, release count, restore speed, failure share, rework rate?
- Do risky features go out dark behind feature flags, and reach full traffic through a canary release?
The fifth metric deserves a note: rework rate joined the set in 2024, and the recovery definition was tightened in 2023 so only failures the change itself caused get counted. Teams tracking the older four-number version should update their boards before benchmarking against anyone.
Section three: recovery checks
- Does every deployment ship with an ID and a named owner before rollout?
- Has the rollback been drilled this quarter, with the recovery time recorded?
- Is the rule written down: restore the prior version when no irreversible migration has run, otherwise toggle the feature off or fix forward?
- Does a blameless review follow every incident within five working days?
The case for drilling is arithmetic, not rhetoric. One documented failure — a four percent spike in payment errors after a deployment labelled d06 — took roughly 190 minutes to unwind, since no one had ever rehearsed the rollback; drilled, the same failure clears in about twenty minutes. An airline systems team that treats rollback like a go-around, drilled until boring, buys that margin for free.
Section four: governance checks
- Is production access least-privilege, with standing keys replaced by short-lived OIDC credentials?
- Do schema changes use expand-and-contract patterns, so a rollback never orphans data?
- Does the quarterly audit sample about ten random changes instead of reviewing the entire population?
- Does a break-glass merge path exist for genuine emergencies, with every use logged?
A caution belongs here: the heavyweight change approval board pattern is associated with worse delivery performance in the research, not better safety. Auditors accept automated controls with evidence trails; they accept meetings less readily than teams assume.
Section five: culture checks
- Do the five CALMS dimensions — culture, automation, lean, measurement, sharing — each have an owner, or does only automation get budget?
- Is the maturity position honest? The ladder ascends from siloed, through automated islands and integration, up to continuous delivery and the learning system, and most teams overestimate their rung by one.
- After the last incident, were approvals added, or was a control automated? The first answer is the reflex; the second is the practice.
Findings that recur across DevOps audits
Four patterns appear so often they deserve pre-warning. First, automation islands: the booking platform, the fare engine and the content site each own a separate pipeline, and none shares a standard. Second, seasonal releases: one grand deploy before the holiday window, carrying a season’s worth of untested interactions. Third, hero dependence: a single engineer who alone understands the deploy, which is a single point of failure with a name badge. Fourth, the tool-first purchase: a platform bought before anyone mapped the value stream, which the adoption evidence scores at 2.40 of 5 — weakest of the three common routes, behind even an organisation-wide mandate at 2.50 and far behind a coached value-stream pilot at 4.25.
Remediating in ninety days
If the audit reads badly, resist the programme launch. The sequence that works: stabilise one value stream first — map it, baseline the metrics, relieve the worst queue. Then automate the road itself: one build per change, a drilled rollback, commit feedback in ten minutes or less. Only then govern and spread: least-privilege access, expiring credentials, sampled audits, and a written standard other teams can copy. Three phases, one quarter each at most, evidence at every step.
Scoring the audit
Fifteen passes means the pipeline is producing evidence continuously, and the next argument is about speed rather than safety. Partials mark the queues. Fails mark the risks that surface at the worst hour of the night. Run the audit quarterly, and put the scores beside the delivery metrics: the two lists move together, which is the whole point. Aviation earned its checklists the hard way, and software gets to inherit them. For wider reading on the aviation side of the house, the aircraft cockpit guide for learners shows where checklist discipline lives in the aircraft, the cabin structure explainer is a useful reminder that systems have layers, and the beginner’s propeller guide makes the case for balancing moving parts — as does any release train.
