18 · Capstone: the end-to-end path
Every piece of this track was one link. The capstone snaps them into a single chain: train → track with MLflow → version with DVC → wrap in FastAPI + Docker → gate with CI/CD → push to ECR → deploy to the cloud → monitor for drift → retrain. That loop, not any single stage, is MLOps.
MLOps is not any single tool — it's the **loop** that connects them. The end-to-end path is: **train** the model → **track** the run with MLflow → **version** data and the artifact with DVC → wrap it in a **FastAPI** service and **Docker** image → gate every change through **GitHub Actions CI/CD** → push the image to **ECR** → **deploy** to the cloud (Beanstalk / EC2 / a managed endpoint) → **monitor** for drift → when drift fires, **retrain** and send the new model right back through the same pipeline. Each stage of this track was one link; the capstone is the whole chain — and the loop closing back to retraining is what makes it MLOps rather than a one-shot deploy.
Without this:
Without the connecting loop, you have isolated capabilities — a model in a notebook here, a Dockerfile there, a CI file somewhere else — but no reliable, repeatable path from a code change to a monitored production model that retrains when the world shifts. The pieces don't add up to MLOps until they're chained.
You've built every link. Now snap them into one chain. This capstone walks the complete end-to-end path that takes the scikit-learn pipeline from bc-py-59 — a model in a notebook — all the way to a monitored, retrainable production service. Read it as the story of one prediction request's whole supporting infrastructure.
1. Train (Ch 1–2). It starts with the model. A reproducible project — pinned dependencies, a fixed seed, a src/ layout — trains the pipeline and serializes it to a single artifact (model.joblib). Reproducibility first, because everything downstream assumes you can rebuild this exact model.
2. Track with MLflow (Ch 4). Every training run logs its params, metrics, and the artifact to MLflow, so "which run was best?" is a query, not a memory. The registry promotes a chosen run None → Staging → Production.
3. Version with DVC (Ch 5). Git versions the code; DVC versions the data and the model. A dvc.yaml pipeline makes the path from raw data → trained artifact reproducible: dvc repro re-runs only what changed.
4. Serve with FastAPI + Docker (Ch 2–3). The model is wrapped in a FastAPI /predict endpoint (a Pydantic request schema validates inputs before predicting) with a /healthz check, then containerized into a Docker image — the same image everywhere.
5. Gate with CI/CD (Ch 6). GitHub Actions runs the tests and linter on every PR (CI), and on merge to main builds the image, pushes it, and deploys (CD) — with secrets and a production approval gate. A broken change never reaches production.
6. Push to ECR (Ch 7). The built image is tagged with the git SHA and pushed to a registry (ECR on AWS): login → tag → push. The cloud pulls this exact artifact — no rebuild, no drift between tested and deployed.
7. Deploy to the cloud (Ch 7). The image runs on the right rung of the managed-vs-control spectrum: Beanstalk for a managed container, EC2 for full control, a SageMaker/Azure ML endpoint for autoscaling ML-native serving. The model is now live behind an HTTPS endpoint.
8. Monitor for drift (Ch 8). Every prediction is logged; PSI/KS watch the live input distribution against the training reference. Operational metrics (latency, errors) ride alongside.
9. Retrain — and loop back. When drift crosses the threshold, an alert fires and triggers retraining: pull fresh labeled data, retrain (step 1), track (2), version (3) — and the new model flows right back through serve → CI/CD → push → deploy → monitor. That return arrow is the point. A one-shot deploy is a project; the loop — deploy → monitor → detect → retrain → deploy — is MLOps.
The consolidated CI/CD workflow below ties build + push + deploy into one file, and the animated pipeline traces the full chain. This is the whole track in one breath: from a model in a notebook to a production model that watches itself and renews itself.
A consolidated `mlops.yml` workflow: a `ci` job (tests + lint on every PR) and a `deploy` job that, only on merge to main and after CI is green, builds the image, pushes it to ECR (login → tag → push by git SHA), and deploys — build + push + deploy tied into one file.
CI/CD pipeline: each stage must pass before the next runs — a failure halts the deploy.
Which sequence correctly orders the core stages of the end-to-end ML lifecycle that this track built?
- The end-to-end path is one chain: train → track (MLflow) → version (DVC) → serve (FastAPI + Docker) → CI/CD → push (ECR) → deploy (cloud) → monitor → retrain.
- A consolidated CI/CD workflow ties build + push + deploy together: tests gate every PR, and a merge to main builds the image, pushes it to ECR by git SHA, and deploys behind an approval gate.
- MLOps is the connecting loop, not any single tool — the return arrow from monitor → retrain → deploy is what turns a one-shot deploy into a model that endures and renews itself.
A mature ML team runs exactly this loop in production: every model change flows train → track → version → serve → CI/CD → registry → deploy → monitor, and a drift alert reopens the loop at retraining — the pipeline that lets them ship and operate models continuously.
If you remove it: You'd have isolated capabilities — a notebook model, a stray Dockerfile, a lone CI file — but no reliable, repeatable path from a code change to a monitored, self-retraining production model.