MLOps Lifecycle

Overview

Why MLOps exists

MLOps applies DevOps principles to machine-learning systems. DevOps versions code and configuration; MLOps also versions data, features, models and the training pipeline itself. The goal is a short path from idea to production model, and a model that keeps performing once it is there.

A model trained once and never touched again will degrade. Data distributions shift, labels go stale, upstream schemas change and business rules evolve. Without a system, teams learn about failures from user complaints instead of dashboards.

> [!IMPORTANT] The closed loop, monitoring feeding back into retraining, is what separates MLOps from a one-time model launch.

The eight-stage lifecycle

• 1. Data ingestion — Raw data lands in a lake or warehouse; schema enforced, PII tagged, lineage recorded — Kafka, CDC, batch exports, REST APIs
• 2. Feature engineering — Raw rows become model inputs on an offline (training) and an online (inference) path — Spark, dbt, feature stores
• 3. Training — Produces an artifact with full reproducibility metadata — MLflow, W&B, Vertex Experiments
• 4. Evaluation — Gates the artifact on a frozen holdout, per-segment fairness slices and business proxies — Holdout sets, slice metrics
• 5. Registration — Artifact enters the registry with stage, signature and lineage — MLflow Registry, W&B Models
• 6. Deployment — Registered artifact moves into serving — Canary, shadow, A/B
• 7. Monitoring — Operational signals (latency, errors) and model-quality signals (drift, output distribution, delayed performance) — Evidently, Arize, Fiddler, WhyLabs
• 8. Retraining — Fires when a signal crosses a threshold — Schedule, drift or decay triggers

CI and CD for ML

CI for ML keeps ordinary unit tests and adds checks on the data and the model. CD for ML adds controlled traffic patterns so a new model meets real traffic gradually.

• Shadow — 100% mirrored — No, logged only — Does it behave sensibly on production traffic?
• Canary — Small share of real traffic — Yes — Is it stable at scale?
• A/B — Split user groups — Yes — Does it improve the business metric?

Google MLOps maturity levels

• 0: Manual — Data scientists train in notebooks and hand off pickle files; engineers re-implement feature pipelines — Where most companies live
• 1: Pipeline automation — Training code runs on a schedule or data trigger; models flow through a registry; deployment keeps human gates — Teams retraining weekly or monthly
• 2: CI/CD automation — New code builds a new training pipeline, which registers a model that deploys automatically — High-volume recommendation, search and ads

> [!TIP] MLOps maturity is a function of release cadence, not tooling sophistication. A team retraining quarterly does not need Level 2; a team retraining hourly cannot survive without it.

The 2026 platform landscape

• Databricks — Lakehouse, MLflow, Feature Store and Model Serving; dominates Spark and Delta Lake teams
• Vertex AI, SageMaker, Azure ML — Integrated managed pipelines per cloud
• Open-source stack — MLflow, Kubeflow Pipelines, Feast, KServe and Evidently; popular for cloud-agnostic setups
• Weights and Biases — Experiment tracking and model registry with strong UX for deep learning teams

Interview questions

• Walk me through the full MLOps lifecycle from raw data to a monitored production model.
• What is the difference between the three Google MLOps maturity levels and when does each apply?
• How do you implement CI/CD for ML? What tests replace or augment standard unit tests?
• What platforms would you choose for MLOps in 2026 and why?
• What is the difference between canary, shadow, and A/B deployment for models?

More MLOps & LLMOps topics

• ML Governance and Compliance
• ML Monitoring and Alerting
• ML Pipeline Orchestration
• ML Security and Adversarial Robustness
• ML Testing Infrastructure
• MLOps CI/CD Automation
• Model Deployment Strategies
• Model Drift Detection
• Model Evaluation — Offline and Online
• Model Packaging and Formats
• Model Registry
• Model Serving