MLOpsThe MLOps lifecycle · MLflow 3.17 · DVC 3.67 · FastAPI · Docker · GitHub Actions · Evidently · Python 3.11+
Dashboard
0%
1
Curious builder0 XP earned · 300 to level 2
0 daysFinish a lesson to begin
Badge collection0 of 6 unlocked
50 small wins to finish your pathNext lesson →

CI/CD for a model service

CI/CD is a pair of practices that move the work after a commit onto a server: continuous integration builds and tests every change as it lands, and continuous deployment takes a change that passed and ships it to an environment without anyone running commands by hand.

Last updated: 19 Oct, 2026 · MLOps

The Pushing to a container registry lesson ended with an image in a registry and a person typing the commands that put it there. Every one of those steps is the same after every change: install, test, build, tag, push, pull on the server, restart the container. CI/CD is where that list stops being a list you follow and becomes a file the repository runs for you.

What continuous integration and continuous deployment actually mean · from the MLOPS Github Action With CICD Pipeline One Shot Tutorial · 8:46 to 10:58

Reading the two halves apart

  • Continuous integration is the half that runs on the way in. Developers merge their changes into a shared branch often, and each merge sets off an automated build and test, so a change that breaks what already worked is caught at the merge rather than in production.
  • Continuous deployment is the half that runs on the way out. Once the checks on the merged change pass, the same automation builds the artifact and puts it on an environment: a development server first, then a staging server, then production.
  • A workflow is the list of steps either half runs, and an event is what sets it off. A push to the main branch and an opened pull request are the two events a model repository uses most.
A pipeline left to right in five stages. A git push, where a commit lands on the main branch, leads to Test, which trains the model and then runs the pytest suite; then Build the image, a docker build from the Dockerfile in the repo; then Push the image, where the tagged image goes to the registry; then Deploy, where the server pulls that tag and runs the container. A dashed blue band marks the test, build and push stages as running on a GitHub-hosted runner, a fresh ubuntu-latest machine per job, and a dashed green band marks the deploy stage as running on your own server. A red arrow drops from the test stage, labelled a test fails, into a panel reading the job stops here: no image is built, nothing is pushed to the registry, and the server keeps serving the version it already has.

What a model service adds to an ordinary pipeline

A web application's pipeline installs, tests, builds and deploys. A model service has the same five stages and three extra problems inside them.

  • The model file is not in the repository. Git holds the code that trains the model, not the trained model, so a fresh checkout on the runner has no artifacts/ directory. Either the pipeline trains the model before it tests, or it pulls the model from wherever it is versioned.
  • The tests need a prediction, not only an import. A service that answers with a number is tested by asking it for a number and checking the shape and the range of the answer.
  • The artifact that ships is an image, not a package. The thing deployed is the container image from the Dockerising the service lesson, which carries the Python version, the pinned libraries and the model together, so the build step is a docker build and the deploy step is a pull and a restart.

Choosing a CI/CD tool

Any of these runs the pipeline above. The one this part uses is GitHub Actions, because the repository is already on GitHub and the runners, the logs and the stored credentials come with it.

ToolWhere it runsWhy a team picks it
GitHub ActionsHosted by GitHub, or on your own machinesThe repository is already there, so no second service has to be connected
JenkinsA server you install and maintainOpen source, highly customisable, and an old large plugin ecosystem
GitLab CIBuilt into GitLabThe team already uses GitLab for code and issues
CircleCICloud hostedEasy to set up and scales out, common in startups
Travis CICloud hostedLong used by open source projects on GitHub, Bitbucket and GitLab
Azure DevOpsMicrosoft hostedThe rest of the stack is already on Azure

Where an automated pipeline earns its keep

  • More than one person on the repository. Two people editing the same transformation break each other's work quietly; a test job on every pull request says so before the merge.
  • A retrained model. New data gives new metrics, and the pipeline is where a model that scores worse than the one in production can be stopped before it ships.
  • A deploy nobody dreads. When shipping is a commit rather than a sequence of eleven commands on a server, a small fix goes out the same day instead of waiting for a release evening.
Watch out. Automating a deploy with no test step in front of it ships broken changes faster than a person would. The order matters more than the automation: tests first, build second, deploy last, with each step reached only when the one before it passed.
Try it yourself
  • Write down every command you ran by hand to put the image in the registry, and mark which of them a server could run instead.
  • Decide which branch of your repository should trigger a deploy, and which should only trigger tests.
  • Name the step in the list above that would have caught the last bug you shipped.
PreviousPushing to a container registry

This is what real progress feels like.