MLOPS & DEPLOYMENT · QUESTION 61
What do CI, CD, and CT mean in machine-learning operations?
On this page
CI continuously checks code and pipeline changes; CD automates delivery or deployment of validated software and models; CT automates model training when defined data or schedule triggers occur. ML pipelines add data validation and model-quality gates to ordinary software checks. Automation should promote only candidates that pass reproducible tests, with monitoring and rollback available.
LET'S MAKE IT SIMPLE
First, the idea in plain English
Software can be tested and released whenever code changes, but machine-learning systems also depend on data and model quality. CI checks changes; delivery prepares a release; deployment makes it live; continuous training can produce a new candidate from updated data. Each step needs checks that match what can go wrong.
A USEFUL COMPARISON
Picture it this way
A bakery checks a recipe and equipment, prepares a batch, and decides whether it meets quality requirements before sale. It may make a new batch when ingredients change, but does not automatically sell every batch. ML automation similarly needs gates between producing a model and serving it.
FOLLOW THE JOURNEY
Automate code checks, model training, and guarded release separately
Distinguish CI, delivery/deployment, and continuous training in an ML lifecycle.
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Production behavior completes the feedback loop.
Code changes trigger CI checks; data triggers a training pipeline; validated model candidates pass release gates before deployment and monitoring.
How to read this visual
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Production behavior completes the feedback loop.
UNDER THE HOOD
How it works, step by step
Continuous integration
Test code, schemas, and pipeline changes.
Why it matters: Early checks catch broken changes before expensive runs.
Continuous training
Create a candidate from approved data and a versioned recipe.
Why it matters: New data should produce a traceable candidate, not an automatic release.
Continuous delivery
Package and validate artifacts for a controlled release.
Why it matters: Quality and compatibility checks belong before production.
Deploy and observe
Release the approved version, monitor it, and keep rollback ready.
Why it matters: Production behavior completes the feedback loop.
OUTSIDE THE TEXTBOOK
A practical example
A daily training job detects a new labeled-data snapshot and starts validation and training. The pipeline records code, data, and model metrics, but promotion stops if a quality or fairness check fails. An approved artifact is deployed to staging for contract tests, then released gradually with an automated rollback condition.
GO A LITTLE DEEPER
Technical details that matter
- Continuous delivery can prepare a release for approval; continuous deployment can release automatically after gates pass.
- Continuous training triggers still need data-quality, model-quality, and safety acceptance criteria.
- Separate model creation from production promotion so a scheduled run cannot silently replace a stable model.
MAKE A GOOD CHOICE
When is this useful?
- Teams releasing code and models frequently with traceability.
- Repeatable pipelines where new data produces evaluated candidates.
- Reducing manual release steps while preserving quality gates.
A small prototype may use scheduled scripts and manual checks. Add automation as deployment frequency, risk, and team needs justify it.
WATCH OUT FOR
Common misunderstandings
- Treating every training run as a production deployment.
- Using code tests alone without validating data and model outcomes.
- Automating retraining without a candidate review or rollback policy.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Pipeline infrastructure adds maintenance and permissions complexity.
- Automated metrics can miss important qualitative regressions.
- Data triggers can create noisy or expensive runs without governance.
WHAT TO REMEMBER
Key takeaways
- 1CI checks changes; CD handles release; CT creates model candidates from data.
- 2ML automation needs data and model gates as well as code tests.
- 3Keep production promotion controlled and reversible.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
Does continuous training mean continuous deployment?
No. Training can create candidates continuously while release remains gated by evaluation, approval, or staged deployment.
What belongs in an ML CI pipeline?
Code and unit tests, schema and data checks, pipeline integration tests, and relevant model validation; the exact scope depends on the system.
SAY IT OUT LOUD
How to explain this in an interview
“CI validates code and pipeline changes; CD prepares or deploys releases; continuous training produces candidate models from new data or schedules. In ML, each stage needs data and model-quality checks in addition to software tests. I would keep training separate from production promotion, require explicit acceptance gates, and make deployments observable and reversible.”
Connect this question to the roadmap topic it supports.