MLOps vs DevOps
MLOps is DevOps with a model in the middle. The pipeline, the environments and the automated deploy carry straight over; what is new is that the thing being shipped is trained from data, so the pipeline also has to train it, and the shipped thing gets worse over time rather than staying still.
Last updated: 19 Oct, 2026 · MLOps
Why models stall in notebooks listed what production asks for. Most of those answers already exist in software engineering, which is why the DevOps versus MLOps video starts on familiar ground before naming the difference.
How DevOps ships a change
In an agile process the work is cut into stories and the stories into sprints, a sprint lasting about two weeks. When a sprint's stories are built they enter a continuous integration and continuous deployment pipeline, which carries them through a row of environments: development first, where the team tests end to end, then a QA environment where the test team signs it off, then staging with another round of checks, and finally production. A bug found anywhere sends the fix back through the same pipeline.
The important property is that the thing moving through those environments does not change on its own. Software can gain a bug, and a bug can be fixed and integrated, but a program that works today works tomorrow on the same input. That single assumption is what MLOps cannot keep.
What a model project adds
A data science project has a lifecycle of its own before anything is shipped: requirement gathering, which belongs to the business analyst, then exploratory data analysis, feature engineering, feature selection, model creation, hyperparameter tuning, deployment, and a retraining approach at the end. The DevOps-versus-MLOps video draws exactly that list, and the point it makes is that the whole list, not the deployment step alone, has to run inside the pipeline.
- The pipeline trains. It is not enough to build and deploy an artefact; the pipeline runs the data stages and fits the model, because the artefact is an output of the data, not of the source code alone.
- Parameters are part of the build. Tuning a model means running it many times with different parameters until the result is good enough, so a run has to be a recorded, repeatable thing rather than an afternoon.
- Retraining is its own pipeline. It sits alongside CI/CD rather than inside it, because it is triggered by data and time rather than by a commit.
- Two kinds of input can break a release. In DevOps, a release is wrong because the code is wrong. Here it can also be wrong because the data changed, which no code review catches.
Why software improves and a model decays
Software, once written, only moves in one direction. Bugs are found and fixed, features are added, and the program that handled a request last year still handles it. A model is fitted to a snapshot of the world. As new data arrives, more users, different behaviour, a changed product, the live data stops looking like the training data and performance falls. Nothing in the code changed; the world did. That is why the lifecycle ends in a retraining approach instead of ending in a deploy.
DevOps and MLOps side by side
| DevOps | MLOps | |
|---|---|---|
| What ships | An application or service | A model, plus the service around it |
| What the pipeline does | Build, test, deploy | Build, train, evaluate, test, deploy |
| Inputs that decide the result | Source code | Source code and the training data |
| Testing | Unit and integration tests | The same, plus a metric on held-out data |
| After release | The behaviour holds | Accuracy drifts as the data moves |
| The extra stage | None | A retraining approach, on its own trigger |
| Versioning | Code | Code, data and models |
Where the distinction changes a decision
- Reusing an existing DevOps stack, where the pipeline, the environments and the container registry carry over and only the model-specific stages are new.
- Planning a release schedule, where a model needs a retraining cadence as well as a deploy cadence, and the two are not the same calendar.
- Writing the definition of done, where a model story is not finished at the deploy: it needs a tracked run, a versioned dataset and a way to notice decay.
Related
- Previous: Why models stall in notebooks
- Next: The MLOps lifecycle
- Reference: MLOps: continuous delivery and automation pipelines in machine learning
- List the environments your team deploys through and mark which ones a model would also need.
- For a service you know, write down what would have to change for its pipeline to train something.
- Name one failure a passing test suite would not catch for a model, and what you would measure instead.
You understood something today that you didn't yesterday.