MLOps is the set of practices that take a model from a notebook to a reliable production service, and keep it reliable as data changes. It borrows from DevOps (automation, CI/CD, monitoring) and adds what is specific to ML: data and model versioning, reproducible training, evaluation gates, and drift detection. This section walks through the lifecycle stage by stage.
A production ML system is a loop, not a line. Data and features are prepared, ideally once, in a way that is identical for training and serving; feature stores exist to guarantee this. Experiments try models, parameters and features, and experiment tracking records every run so results are reproducible and comparable. The best candidate is registered in a model registry, which versions it with its lineage and controls promotion. The approved version is deployed for batch scoring or online inference. Monitoring watches input data, predictions and, when labels arrive, real performance; drift or degradation triggers retraining, and the loop starts again.
Studies of production ML, most famously "Hidden Technical Debt in Machine Learning Systems" (Sculley et al., 2015), point out that the model code is a small part of a real system. Most failures come from the surroundings: training data that differs from serving data, untracked experiments nobody can reproduce, manual deployments, and silent degradation as the world changes. MLOps makes each of those failure points explicit and automates the checks.
The pages in this section map onto the loop. Experiment tracking covers the "try many things and remember what happened" stage. Feature stores solve training-serving skew and point-in-time correctness for features. The model registry is the hand-off point between data scientists and the serving platform, with versioning, aliases and promotion gates. Model monitoring closes the loop by detecting data drift, concept drift and performance decay, and deciding when to retrain. Read them in that order if you are building a platform from scratch.
| Level | What it looks like | Typical next step |
|---|---|---|
| 0: Manual | Notebooks, hand-copied model files, manual deploys | Track experiments; register models |
| 1: Pipeline automation | Training pipeline runs on schedule; models registered automatically | Add evaluation gates and monitoring |
| 2: CI/CD for ML | Code, data and model changes tested and deployed automatically; monitoring triggers retraining | Refine: shadow deployments, per-slice gates, cost controls |
These levels follow the widely cited Google Cloud MLOps guide. Most teams do not need level 2 for every model; match the investment to how often the model changes and how costly its mistakes are.