CI/CD for ML: Same GitHub Actions, Different Artifact
Your CI/CD pipeline deploys code. Ours deploys models. Same tools: GitHub Actions, ArgoCD, Docker, DVC, MLflow. Here is the 7-job ML pipeline.
Your CI/CD pipeline deploys code. Ours deploys models. Same tools.
GitHub Actions. ArgoCD. Docker. DVC. MLflow. Same stack you already run. The only difference is what triggers the pipeline and what gets deployed.
Code pipeline: git push > build > test > deploy
ML pipeline: data change > retrain > evaluate > deploy
The 7-Job ML Pipeline
| Job | What It Does | Failure Action |
|---|---|---|
| 0. Preflight | 7 infra checks in 5 min (MLflow up? MinIO? DVC?) | Fail fast |
| 1. Data + Features | DVC pulls dataset, feature engineering runs | Stop on schema error |
| 2. Train + Gate | Train candidate, compare vs champion | If candidate loses, skip Jobs 3-6 |
| 3. Export | Get champion model URI from MLflow | Stop on registry error |
| 4. Build | Build transformer container | Stop on build error |
| 5. GitOps | Patch KServe YAML, push to git | ArgoCD watches repo |
| 6. Verify | ArgoCD syncs, health check, 3 smoke tests | Rollback on failure |
Jobs 3 and 4 run in parallel.
The Quality Gate (Job 2)
This is the part most ML pipelines get wrong. They deploy every model that finishes training. No comparison. No gate. No safety net.
Our pipeline has a hard stop at Job 2. If the new model is not better than the current champion, the deploy never happens. The workflow succeeds but deployment is skipped.
That’s not a failure. That’s the pipeline protecting production.
The GitOps Flow
Job 5 patches the KServe YAML with the new model URI and pushes to git. ArgoCD watches the repo. When the manifest changes, ArgoCD syncs automatically.
No kubectl apply. No manual deploys. Git is the source of truth. (More on model versioning in Part 16: ML Governance.)
This is Part 17 of the MLOps for DevOps Engineers series. For weekly updates, join the newsletter.