CI/CD, automation, and infrastructure for MLOps
CI/CD, automation, and infrastructure for MLOps tests whether you can move code, data, environments, and models through environments repeatably. Treat Azure ML workspaces, compute, datastores, endpoints, and roles as infrastructure as code with Bicep or Terraform; treat training and deployment as pipeline code with Azure CLI v2 YAML or SDK.
Core rules
- Trigger CI on pull requests: lint, unit tests, component tests, and YAML validation. Trigger CD on merge or release.
- Use service connections with workload identity federation, not stored secrets. Keep environment-specific values in variable groups or parameter files.
- Gate promotion on automated checks: model metric threshold, fairness check, schema test, and smoke test.
- Register the model with lineage, deploy to staging, run integration tests, require approval for production, and keep a rollback path.
Worked example
A PR changes a training component. CI runs unit tests and a short training job on sample data. On merge, CD runs the full pipeline, registers the model if validation AUC is at least 0.85, deploys to staging, and calls the endpoint with a known payload. A production approval then promotes the same model version and environment; no manual portal edits are allowed.
Traps
- Manual portal deployments that cannot be reproduced.
- Hard-coded subscription IDs or secrets in YAML.
- No model quality gate before production.
- No rollback or previous-version artifact.
- Treating infrastructure drift as acceptable.