ML CI/CD extends traditional Continuous Integration/Continuous Deployment to ML systems — adding a third "C," Continuous Training, since ML pipelines need to test and deploy not just code, but data and models too.
What's Different From Traditional Software CI/CD
| Traditional CI/CD | ML CI/CD |
|---|---|
| Tests: does the code work correctly? | Tests: does the code work correctly, AND does the model still perform well? |
| Deploys: new code | Deploys: new code, AND potentially a newly trained model |
| Triggered by: a code commit | Triggered by: a code commit, OR fresh data, OR detected drift |
The Three C's
- Continuous Integration: automatically test code changes — including data validation and preprocessing logic tests, not just standard unit tests
- Continuous Deployment: automatically deploy validated code and models to production
- Continuous Training: automatically retrain and re-evaluate models as new data arrives — see ML Retraining
A Basic GitHub Actions Workflow for ML
# .github/workflows/ml-ci.yml
name: ML CI Pipeline
on:
push:
branches: [main]
jobs:
test-and-validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.11"
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run unit tests
run: pytest tests/
- name: Validate data schema
run: python scripts/validate_data.py
- name: Train and evaluate model
run: python scripts/train_and_evaluate.py
- name: Check model meets minimum performance threshold
run: python scripts/check_model_quality.py --min-f1 0.75The final step is the ML-specific addition traditional CI/CD has no equivalent for — a pipeline can pass every code test perfectly while still producing a model that shouldn't ship, so an explicit quality gate on model performance is essential before deployment proceeds.
What "Testing" Means for ML Specifically
| Test Type | What It Checks |
|---|---|
| Unit tests | Individual functions (a custom transformer, a feature calculation) behave correctly |
| Data validation tests | Incoming data matches the expected schema, types, and value ranges |
| Model quality tests | The newly trained model meets a minimum performance bar before deployment proceeds |
| Integration tests | The full pipeline — preprocessing through prediction — runs end to end without errors |
Practical Use Cases
- Automating what would otherwise be manual, error-prone, easy-to-skip validation steps before every deployment
- Giving a team confidence that a code or data change won't silently ship a broken or degraded model
Common Mistakes
- Running only standard code unit tests, with no automated check on the resulting model's actual performance before deployment.
- Skipping data validation in the pipeline, letting malformed or unexpected data silently train (and potentially deploy) a bad model.
Interview Relevance
Q: "Why does ML CI/CD need a third 'C' beyond Continuous Integration and Continuous Deployment?" Traditional software behavior depends only on code, so CI/CD testing and deploying code is sufficient; ML system behavior also depends on the data it's trained on, which keeps changing — Continuous Training closes that gap by automatically retraining and re-validating models as fresh data arrives, not just when code changes.
Practice Question
Design a minimal CI/CD quality gate that would catch a newly trained model that passes all code tests but has quietly regressed in accuracy compared to the current production model.
