CI/CD for ML
Beginner 12 min read CI/CD for ML

CI/CD for ML

DevOps automation, applied to models

ML CI/CD extends classic DevOps automation to models: test the code AND the data AND the model, then ship the artifact — not just the binary. CI catches broken code, bad data and busted pipelines; CD delivers a promotable model safely.

mlopsci/cdautomationmodel deploymentpipeline
Prerequisites: CI/CD Fundamentals Model Registry
Before we start

What you will learn

  • Explain what CI and CD mean for models, not just code
  • Lay out the stages of an ML CI pipeline
  • Describe how a model moves from registered artifact to deployment
Introduction

What is this?

CI/CD for ML automates the quality and delivery loop around models: CI runs tests on code, data and training outputs; CD packages and ships the validated artifact through staged environments to production. The artifact under automation is a model version, not just a compiled binary.

Motivation

Why do you need it?

  • Models add failure modes code doesn't have: data drift, overfitting, silent degradation.
  • Manual 'upload model, restart server' is slow, error-prone and unattributable.
  • Automation makes retraining a routine operation instead of a hero deployment.
  • Gates between stages keep bad models out of production before they cost money.
Think about it

Mental model

Imagine

An airline's pre-flight and gate process

Think of

ML CI/CD

Before any flight (deployment) there are checks (CI): paperwork, fuel plan, weather, crew. Then a staged boarding process with gates (CD): approve, board, pushback. A bad inspection aborts before anyone boards.

Mechanics

How it works

  • A commit pushes code, and/or the registry records a new model version.
  • CI runs: lint, unit tests, data schema checks, quick train smoke test, model metric assertions.
  • The model is registered with evidence: metrics vs champion, data version, code SHA.
  • CD promotes the artifact through staging: deploy, validate, then production.
  • Gates pause progression for human approval where risk demands it.
  • Deployment is registered in the registry as 'serving' for lineage.

The ML CI/CD loop from commit to production.

Commit / new model
CI checks
Register with evidence
Staging deploy
Approval gate
Production deploy
Real world

In production

  • Every commit runs unit tests plus a 5-minute smoke train on a subset of data.
  • A validated model version auto-promotes to staging and pages the owner for prod.
  • Rollbacks reuse older registry versions through the same CD path.
Guidelines

Best practices

  • Treat data as a first-class input to CI, pinned and versioned.
  • Automate promotion to staging; gate production behind evidence and approval.
  • Make every pipeline stage idempotent and re-runnable.
  • Record every deployment and its source artifact in the registry.
Watch out

Common mistakes

  • Copying a code-only CI pipeline and calling it 'ML CI' with no data/model checks.
  • Deploying a model nobody registered — no lineage, no rollback story.
  • Auto-promoting to production with no gate or champion comparison.
  • Heavy CI that takes hours, so nobody runs it.
When things break

Debugging tips

  • 'CI is green but prod broke' — check whether CI actually tested the data/model, not just syntax.
  • 'Stop stuck in staging' — read the gate's logs; it may be a metric below champion threshold, not a crash.
  • 'Rollback pain' — confirm every prod version was registered with a deploy record.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which is a uniquely ML concern inside CI?

2

A deploys source code only; a model's lineage doesn't matter for rollback.

Go deeper

Official documentation

MLOps with GitHub Actions guide
docs
GitLab CI/CD — MLOps
docs