Delivery
Progressive Delivery
Progressive delivery reduces release risk by exposing changes gradually and using health signals to decide whether to continue, pause, rollback, or disable functionality.
Delivery patterns
| Pattern | Use when |
|---|---|
| Rolling deployment | Changes are low risk and instances are interchangeable. |
| Blue-green | Fast rollback matters and duplicate capacity is acceptable. |
| Canary | Risk should be limited to a small traffic slice first. |
| Feature flag | Functionality needs independent enablement or fast disablement. |
| Shadow traffic | Behavior should be observed without user-facing impact. |
Signal requirements
Progressive delivery only works when signals are meaningful.
Required signals usually include:
- Request rate, error rate, and latency.
- Saturation or resource pressure.
- Business or user-flow success metrics.
- Dependency health.
- Logs and traces for the changed path.
Release flow
Guardrails
- Define rollback and disablement before rollout.
- Keep canary duration long enough to observe real traffic.
- Use automated analysis where signals are reliable.
- Include manual approval for high-risk production changes.
- Link each rollout to the artifact, commit, and change request where required.
Watchouts
- Canarying without enough traffic creates false confidence.
- Feature flags are not permission checks.
- Blue-green doubles capacity needs during rollout.
- Too many long-lived flags become hidden production complexity.