{"id":1229,"date":"2026-10-18T11:25:00","date_gmt":"2026-10-18T11:25:00","guid":{"rendered":"https:\/\/aircrafto.com\/blog\/aviation-devops-pre-flight-checklist\/"},"modified":"2026-10-18T11:25:00","modified_gmt":"2026-10-18T11:25:00","slug":"aviation-devops-pre-flight-checklist","status":"publish","type":"post","link":"https:\/\/aircrafto.com\/blog\/aviation-devops-pre-flight-checklist\/","title":{"rendered":"A DevOps Pre-Flight Checklist for Aviation Software"},"content":{"rendered":"

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.<\/p>\n

Why DevOps discipline suits flight-ops software<\/h2>\n

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 \u2014 small inspected increments, checklists, rehearsed emergencies \u2014 translate almost untouched. The research field that grew around this translation is substantial; for the full background, the Ops Atlas DevOps guide<\/a> assembles the metrics, frameworks and history in one reference.<\/p>\n

How to run the audit properly<\/h2>\n

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.<\/p>\n

Section one: flow checks<\/h2>\n
    \n
  1. Has the value stream been mapped within the last year, with waiting times measured rather than estimated?<\/li>\n
  2. Do branches live less than two days, with trunk-based development the documented default?<\/li>\n
  3. Is there exactly one automated build per change, promoted unchanged through every environment?<\/li>\n
  4. Does deployment frequency suit the risk \u2014 small releases several times a week, not a seasonal big bang?<\/li>\n<\/ol>\n

    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.<\/p>\n

    Section two: feedback checks<\/h2>\n
      \n
    1. Does any commit receive build-and-test feedback in roughly ten minutes or less?<\/li>\n
    2. Are the five delivery metrics published where the team can see them \u2014 flow time, release count, restore speed, failure share, rework rate?<\/li>\n
    3. Do risky features go out dark behind feature flags, and reach full traffic through a canary release?<\/li>\n<\/ol>\n

      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.<\/p>\n

      Section three: recovery checks<\/h2>\n
        \n
      1. Does every deployment ship with an ID and a named owner before rollout?<\/li>\n
      2. Has the rollback been drilled this quarter, with the recovery time recorded?<\/li>\n
      3. Is the rule written down: restore the prior version when no irreversible migration has run, otherwise toggle the feature off or fix forward?<\/li>\n
      4. Does a blameless review follow every incident within five working days?<\/li>\n<\/ol>\n

        The case for drilling is arithmetic, not rhetoric. One documented failure \u2014 a four percent spike in payment errors after a deployment labelled d06 \u2014 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.<\/p>\n

        Section four: governance checks<\/h2>\n
          \n
        1. Is production access least-privilege, with standing keys replaced by short-lived OIDC credentials?<\/li>\n
        2. Do schema changes use expand-and-contract patterns, so a rollback never orphans data?<\/li>\n
        3. Does the quarterly audit sample about ten random changes instead of reviewing the entire population?<\/li>\n
        4. Does a break-glass merge path exist for genuine emergencies, with every use logged?<\/li>\n<\/ol>\n

          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.<\/p>\n

          Section five: culture checks<\/h2>\n