DevOps vs MLOps: what changes when your product ships a model

DevOps and MLOps share a goal: getting changes into production safely and often. The difference is what changes. DevOps ships code. MLOps ships code, data and models, and models can get worse without anyone touching them.

Two systems I have built show the difference well.

DevOps: shipping code with confidence

Hexenex ERP is a NestJS and Prisma API with a Next.js web app. Its pipeline runs on every push to the main branch:

1. GitHub Actions builds the API and the web application.
2. It uploads an atomic release bundle over SSH, so a half-uploaded release is never live.
3. It keeps the production environment file in place and restarts the app server.
4. It verifies the login page and its static assets before calling the deploy done.

One lesson from that project: the shared hosting runtime once hung Prisma's schema engine during migrations. So routine deployments skip migrations, and a reviewed release can switch them on explicitly with a time limit. Good DevOps is often about making the risky step deliberate.

The DevOps checklist, in short:

• Builds and tests run automatically.
• Releases are atomic and easy to roll back.
• Secrets never live in the repository.
• Deploy targets are restricted to exactly where the app belongs.
• Something checks that the app is actually up after a deploy.

MLOps: shipping models that keep learning

SecureOps is a network detection and security-decision pipeline. Packets are collected and analysed, a reinforcement-learning policy informs the firewall decision, and the model is trained around Azure ML. That is where MLOps starts to matter.

• Data is part of the release. The model is only as good as the traffic it learned from, so training data needs versions just like code.
• Performance drifts. Traffic patterns change. A model that was right last month can be wrong today without a single commit.
• Retraining needs a rule. In SecureOps a configured threshold decides when to retrain and redeploy, connecting monitoring to the next learning cycle.
• Two paths, kept separate. The traffic path makes security decisions understandable; the learning path explains how the model changes.

Side by side

• What changes: DevOps ships code. MLOps ships code, data and models.
• What breaks: DevOps breaks on bad code. MLOps can break on new data, even with perfect code.
• What you monitor: DevOps watches uptime, errors and latency. MLOps watches those plus model quality and drift.
• When you release: DevOps releases on a merge. MLOps also releases when a retraining rule fires.

A minimal MLOps pipeline to start with

You do not need a platform team to begin. Start with these steps and automate them one at a time:

1. Version the data. Snapshot the training data with an ID, the same way you tag a release.
2. Train reproducibly. One script or pipeline that anyone can rerun and get the same model.
3. Evaluate against a fixed test set. Record the metrics that matter for the decision the model makes.
4. Register the model. Store each model with its data version, code version and metrics.
5. Deploy behind the same pipeline as your code. Including a way to roll back to the previous model.
6. Monitor in production. Watch inputs and outputs, not only uptime.
7. Retrain on a rule. A threshold, a schedule or a drift alert, written down and automated.

What to monitor

• Input drift: are the features the model sees changing compared with training?
• Prediction distribution: is the model suddenly predicting one class much more often?
• Feedback: where you get ground truth later, compare it with what the model said.
• Latency and cost: models can be slow or expensive in ways code is not.

Common mistakes

• Training-serving skew: features are computed one way in training and another in production.
• No rollback for models: code can be reverted in seconds, but nobody kept the previous model.
• Manual retraining: a model retrained "when someone remembers" eventually is not retrained at all.
• Monitoring only the server: the service is up, but its answers have quietly become wrong.

Where DevSecOps fits

Security is not a separate phase. In both systems it lives in the pipeline: least-privilege deploy targets, secrets in the platform rather than the code, and checks before production.

If your team ships code by hand or has a model nobody has retrained since launch, that is the first thing I would fix. Here is how I approach DevOps and MLOps.