Deployment strategies
Design a deployment strategy
Every strategy here trades blast radius against cost and complexity. Learn what each one limits.
| Strategy | What it does | Limits damage by |
|---|---|---|
| Blue-green | Two identical environments; switch traffic at once | Instant rollback — switch back |
| Canary | Small slice of traffic to the new version, then widen | Fraction of users exposed |
| Ring / progressive exposure | Successive audiences: internal → early adopters → everyone | Audience, over time |
| A/B testing | Two versions in parallel to measure behaviour | Not a safety mechanism — a product experiment |
| Feature flags | Ship dormant code; enable at runtime | Decouples release from deploy |
The distinction that gets tested
A/B testing is not a deployment safety strategy. Canary and ring exist to limit who is hurt by a bad release. A/B testing exists to find out which variant performs better against a business metric. Both put two versions in front of users; only one is about risk.
Feature flags are orthogonal to all of it. They decouple release from deployment: code ships to production disabled, and you turn it on later without redeploying. That is what makes an instant kill switch possible — the fastest rollback available, because nothing has to be rebuilt or redeployed.
Mapping to Azure Pipelines
Only runOnce, rolling and canary are strategy: keywords. Blue-green and ring are patterns you build from environments, slots, traffic routing and approvals.
Primary sources