A Route Flown Automatically, End to End

Opening Scene

Modern aviation automation can now handle an increasingly large share of a route almost entirely on its own — from structured takeoff procedures through cruise to guided approach — with the human crew from Article 12 supervising rather than manually operating every single step themselves. This didn’t happen all at once. It’s the accumulated result of automating one piece at a time — navigation, altitude management, approach guidance — until the individual pieces added up to something approaching a genuinely end-to-end automated capability, still deliberately supervised throughout.

That same accumulated, end-to-end automation is exactly what a mature CI/CD/CT pipeline provides for the model lifecycle this entire series has covered.

In Plain English

CI/CD/CT — continuous integration, continuous deployment, and continuous training — refers to a fully automated pipeline that takes a model from code change through testing, deployment, and even ongoing retraining, largely without manual intervention at each individual step. This is the accumulated result of automating each individual piece this series has covered — readiness checks (Article 2), approval gates (Article 3), gradual rollout (Article 4), monitoring (Article 5), drift-triggered retraining (Article 9) — into one connected, largely automated system.

The Old Way

Before mature CI/CD/CT pipelines existed, each step in this series’ lifecycle was typically handled manually and separately, the same way early aviation automation handled only individual pieces of a flight rather than anything approaching end-to-end automation:

Manually running each step of a software release process separately, before CI/CD automation matured in general software engineering.
Manually coordinating a complex, multi-stage manufacturing process step by step, before automated production lines matured.
Manually re-running each stage of a research pipeline separately, before automated research workflow tools existed.

In each case, manual coordination between individually automated pieces was itself a significant source of delay, inconsistency, and error, even when each individual piece worked well on its own.

What’s Changing (and Why AI Is the Reason)

CI/CD practices, well-established in general software engineering, have been increasingly adapted and extended specifically for the model lifecycle, adding the “continuous training” piece that’s genuinely distinct from traditional software CI/CD.
Connecting drift detection (Article 6) directly to automated retraining and redeployment, still passing through the readiness checks and approval gates covered earlier in this series, closes a loop that used to require substantial manual coordination between separate teams and tools.
As deployment frequency has increased across the industry, fully automated pipelines have shifted from an advanced, aspirational capability to something closer to a genuine competitive necessity for organizations deploying models at real scale.

The Metaphor, Fully Extended

Airport Operations	CI/CD/CT Pipeline Concept
Automating individual pieces of a flight — takeoff, cruise, approach	Automating individual pieces of the model lifecycle — testing, deployment, monitoring
An accumulated, near end-to-end automated flight capability	A fully automated, connected CI/CD/CT pipeline
A human crew supervising rather than manually operating every step	A human team supervising rather than manually triggering every pipeline stage
Automated systems still passing through required checks and clearances	Automated pipelines still passing through readiness checks and approval gates
Detecting a condition automatically and adjusting course	Detecting drift automatically and triggering retraining
Early aviation automation handling only individual, disconnected pieces	Early MLOps practice handling each lifecycle step manually and separately

For Beginners: What to Actually Do

Understand CI/CD/CT as the accumulated, connected result of automating the individual pieces covered throughout this series, not a single separate technique to learn in isolation.
Recognize that automation doesn’t remove the underlying discipline this series has covered — readiness checks, approval gates, monitoring — it just executes that discipline consistently and automatically.
If your organization has a CI/CD/CT pipeline, understand what it actually automates and where genuine human oversight, from Article 12, still deliberately remains.

For Practitioners and Leaders: The Deeper Layer

Invest in connecting this series’ individual disciplines into a genuinely integrated pipeline, rather than leaving them as separate, manually-coordinated steps — the coordination overhead itself is a real, often underestimated cost.
Maintain deliberate human oversight points within an automated pipeline, echoing Article 12’s human-in-the-loop principle, rather than assuming full automation is automatically the right goal for every step.
Recognize automated CI/CD/CT capability as an increasingly genuine competitive factor for organizations deploying models frequently and at real scale.

Quick Recap

CI/CD/CT pipelines automate the model lifecycle end to end — testing, deployment, and continuous training — connecting the individual disciplines covered throughout this series.
This mirrors aviation’s accumulated automation of individual flight phases into something approaching genuine end-to-end capability, still deliberately supervised.
Extending CI/CD practices with continuous training, and connecting drift detection directly to automated retraining, closes gaps that used to require substantial manual coordination.
Full automation doesn’t remove this series’ underlying discipline — it executes it consistently, with deliberate human oversight retained where it genuinely matters.

Where This Fits in the Series

Article 17 covered the real cost of running deployed models; this article covered how far the whole process can now run automatically. Article 19 looks at a genuinely human challenge that automation doesn’t solve — when two towers give conflicting instructions.