Release & Rollback Policy¶
Rules governing when and how releases are cut and reverted.
Release Cadence¶
| Environment | Trigger | Approvals Required |
|---|---|---|
dev |
Every push to main |
None |
staging |
Manual trigger after CI passes | 1 reviewer |
production |
Manual trigger + quality gates pass | 2 reviewers |
Quality Gates Before Release¶
All of the following must pass before a production deploy:
- All unit and integration tests green (
pytest) rufflinting and formatting check passes- DVC pipeline reproduces deterministically (
dvc repro --dry) - Model metrics meet or exceed champion (see Baseline & Success Metrics)
- No HIGH severity findings in container image scan
Rollback Process¶
Rollbacks are performed manually across three independent layers. Each layer can be rolled back independently as needed.
Service rollback (Helm)¶
Revert to the last known good Helm release:
See Deployment Recovery Runbook for the full procedure.
Model rollback (MLflow)¶
Revert the champion alias to the previous registered model version:
See Model Rollback & Recovery Runbook for the full procedure.
Data rollback (DVC)¶
Restore DVC-tracked artifacts to a prior commit:
Notes¶
- Rollbacks are not automated.
- All rollback decisions require human review.
- After any rollback, the CI pipeline should be re-run to confirm system state.