L11. Deployment Strategies: Blue-Green, Canary, Ring & Feature Flags
Blue-green gives instant rollback, canary limits blast radius through progressive exposure, ring-based deployment structures that exposure into named waves, and feature flags decouple deploy from release entirely.
Blue-Green Deployment: Near-Instant Rollback
Blue-green deployment maintains two identical production environments called blue (currently live) and green (next version). To deploy, you run the new version in the green environment, run validation tests, then switch all traffic from blue to green using a load balancer, DNS flip, or traffic manager.
The beauty is instant rollback: if a problem is discovered immediately after the switch, you simply flip traffic back to blue, which was never touched and still runs the previous code. This is fundamentally faster than a rolling in-place update, where the previous version is gradually replaced and no untouched copy remains.
Canary Deployment: Progressive Risk Mitigation
Canary deployment releases a new version to a small slice of traffic first (say 5%), monitors health metrics for errors and latency, and gradually increases traffic (to 25%, then 50%, then 100%) only if signals stay healthy. If a problem is detected during the early percentage, traffic is rolled back to the previous version before the blast radius grows.
Unlike blue-green's all-at-once switch, canary is progressive. It detects issues before they hit 100% of users, making it invaluable for catching bugs or performance regressions that only show up under real traffic patterns.
Ring-Based Deployment: Structured Waves of Risk
Ring-based deployment progresses through predefined "rings" of increasing user scope: Ring 0 (internal team), Ring 1 (early adopter customers), Ring 2 (general availability). Each ring is validated before promoting to the next. This adds structure to the canary concept: instead of arbitrary percentages, rings are named stages aligned to business risk appetite.
Feature Flags: Decouple Deployment from Release
Feature flags (feature toggles) decouple code deployment from feature release. New code is deployed to production with the feature turned off (dark), then enabled for specific users or a percentage of traffic later without any new deployment. Azure App Configuration Feature Manager is the Azure-native service for this.
This is powerful for safety: code can merge and ship during a business lull, then the feature is enabled during peak support hours when on-call teams are standing by.
A/B Testing vs Canary
A/B testing and canary deployment are distinct concepts, though both serve percentages of traffic. A/B testing serves two variants concurrently to measure a business or UX outcome (Does variant B convert better?). Canary is about deployment safety (Does the new code run without errors?). They answer different questions.
Deployment Slots and Instant Swap
Azure App Service provides deployment slots: a staging slot is warmed up and validated, then swapped with production with zero downtime. The previous production slot becomes the new staging slot, so instant rollback is just another swap.
Comparison: Core Strategies
| Strategy | Rollback Speed | Blast Radius Control | Best For |
|---|---|---|---|
| Blue-Green | Near-instant | All-or-nothing | Critical services |
| Canary | Gradual (percentage) | Limited to current % | Detecting regressions |
| Ring-Based | Per-ring promotion | Structured waves | Enterprise phased rollout |
| Feature Flag | Percentage or user | Percentage of traffic | Safe dark deployments |
| Deployment Slots | One-swap instant | All traffic | Azure App Service apps |
Hotfix Paths
High-priority security fixes need a fast-tracked pipeline path that skips slower, non-essential gates (performance testing, extended soak periods) while keeping mandatory gates (security scans, approvals, automated tests) in place. This balances speed with safety. Exam tip: The AZ-400 exam tests when to use each strategy. Canary is the most commonly tested because it's the most practical for detecting real issues before they hit 100% of users.
- ✓Blue-green deployment keeps two identical environments and switches traffic between them all at once, enabling near-instant rollback by switching back to the previous environment
- ✓Canary deployment releases a new version to a small subset of traffic first and expands exposure gradually only if health signals stay good, minimizing the blast radius of a bad release compared to switching all traffic at once
- ✓Ring-based deployment promotes a release through predefined rings of increasing scope (e.g., internal users, then early adopters, then general availability), validating at each ring before advancing
- ✓Feature flags decouple code deployment from feature release: code can ship to production turned off, then be enabled for specific users or a percentage of traffic later without a new deployment, and Azure App Configuration Feature Manager is the Azure-native implementation
- ✓A/B testing serves two variants concurrently to compare a business or UX outcome metric, which is a different goal from canary deployment's purpose of limiting the blast radius of a risky release
1. What is the key advantage of blue-green deployment compared to a rolling in-place update?
2. A team wants to release a new version to production but limit exposure to just 5% of traffic initially, expanding gradually only if error rates stay low. Which deployment strategy is this?
3. A team wants to deploy a new feature's code to production now but not actually expose it to any users until a specific date, and then only to 10% of users initially. What technique enables this without a new deployment when the feature is turned on?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.