Deployment Strategies: Blue-Green, Canary & Ring
Design deployment strategies that minimise risk and downtime. Compare blue-green, canary, ring-based, rolling, progressive exposure, feature flags, and A/B testing with real scenarios.
Why Deployment Strategies Matter
Think of renovating a restaurant while it is still open.
Option A: close the restaurant for a week, renovate everything, reopen (downtime). Option B: renovate one section at a time while the rest stays open (rolling). Option C: build a second identical restaurant next door, move customers over when it is ready, then demolish the old one (blue-green).
Each option has different risk levels, costs, and customer impact. Deployment strategies are the software equivalent — they determine how you move new code into production without breaking things for users.
The Six Deployment Strategies
Blue-Green Deployment
Maintain two identical production environments — Blue (current) and Green (new).
How it works:
- Blue is live, serving all traffic
- Deploy the new version to Green
- Test Green thoroughly (smoke tests, synthetic monitoring)
- Switch the load balancer/traffic manager to route traffic from Blue to Green
- Green is now live — Blue becomes the instant rollback target
- If anything goes wrong, switch back to Blue in seconds
Rollback: Instant — flip the traffic router back. Cost: High — you maintain two full production environments simultaneously. Best for: Mission-critical applications where instant rollback justifies the infrastructure cost.
Canary Deployment
Route a small percentage of traffic to the new version, then gradually increase if metrics stay healthy.
How it works:
- Deploy new version to a small subset of servers (the “canary”)
- Route 5% of traffic to the new version
- Monitor error rates, latency, CPU, memory, and business metrics
- If healthy, increase to 25%, then 50%, then 100%
- If problems detected, route all traffic back to the old version
Rollback: Fast — route traffic away from the canary instances. Cost: Low — only a fraction of infrastructure runs the new version initially. Best for: High-traffic applications where you want real-user validation before full rollout.
Ring-Based Deployment
Deploy to progressively larger groups of users, defined by “rings.”
How it works:
- Ring 0 — internal team and canary users (10-50 people)
- Ring 1 — early adopters and beta users (1,000 people)
- Ring 2 — broader production audience (100,000 people)
- Ring 3 — all users (everyone)
Each ring has bake time — a mandatory waiting period to observe for issues before expanding. Microsoft uses ring-based deployment for M365 and Windows updates.
Rollback: Remove users from a ring or revert the ring. Cost: Moderate — requires user targeting infrastructure. Best for: SaaS products with diverse user bases where different populations have different risk tolerances.
Rolling Deployment
Update servers one at a time (or in small batches) while keeping the service running.
How it works:
- Take Server 1 out of the load balancer
- Deploy new version to Server 1
- Run health checks — if healthy, add Server 1 back
- Repeat for Server 2, 3, 4…
Rollback: Redeploy the old version in the same rolling fashion (slow). Cost: Low — uses existing infrastructure with no duplication. Best for: Stateless services behind load balancers with many identical instances.
Watch out: During a rolling deployment, both old and new versions coexist. Your application must handle this — APIs need backward compatibility and database schemas must support both versions simultaneously.
A/B Testing
Route different user segments to different versions to measure business impact, not just technical health.
How it works:
- 50% of users see Version A (control)
- 50% of users see Version B (experiment)
- Measure conversion rate, engagement, revenue, or other business KPIs
- Roll out the winning version to 100%
Key difference from canary: A/B testing compares business metrics. Canary compares technical health. A/B testing is a product decision tool; canary is a deployment safety mechanism.
Feature Flags (Feature Toggles)
Decouple deployment from release. Deploy code to production with the feature hidden behind a flag. When ready, flip the flag to enable it — no redeployment required.
if (featureManager.IsEnabled("NewCheckout"))
{
return ShowNewCheckout();
}
return ShowClassicCheckout();Strategy Comparison
| Strategy | Risk Level | Rollback Speed | Infra Cost | Best For |
|---|---|---|---|---|
| Blue-Green | Very low | Instant (switch LB) | High (2x infra) | Critical apps needing instant rollback |
| Canary | Low | Fast (reroute traffic) | Low (small canary pool) | High-traffic apps, real-user validation |
| Ring-Based | Low | Moderate (revert ring) | Moderate | SaaS with diverse user populations |
| Rolling | Medium | Slow (redeploy all) | Very low (no duplication) | Stateless services, large server fleets |
| A/B Testing | Low | Fast (route to control) | Low | Product experiments, business metric validation |
| Feature Flags | Very low | Instant (toggle OFF) | None (same deployment) | Decoupling deploy from release, trunk-based dev |
Feature Flags with Azure App Configuration
Azure App Configuration Feature Manager provides enterprise-grade feature flag management:
- Centralised management — toggle features without code deployments
- Percentage filter — enable for 10% of users, gradually increase
- User targeting filter — enable for specific users or groups
- Time window filter — enable during business hours, disable nights/weekends
- Custom filters — browser type, region, subscription tier
Feature flags have a lifecycle: development (toggle for devs) to release (percentage rollout) to operational (kill switch) to retirement (remove the flag and dead code). Stale flags become technical debt — always set expiry dates.
Scenario: Kai combines canary with feature flags
🚀 Kai at Launchpad Labs ships a major dashboard redesign. His strategy:
- Deploy the new code to all Kubernetes pods with the feature flag OFF
- Enable the flag for internal team only (Ring 0) — 10 people test for a day
- Expand to 5% of users via percentage filter (canary phase) — monitor error rates and load times
- Expand to 25%, then 50%, watching Datadog dashboards at each stage
- Full rollout — enable for 100% of users
- Cleanup — after two weeks of stability, Kai removes the flag and old code path
If any stage shows problems, Kai disables the flag instantly — no pod redeployment needed. The old dashboard appears for all users while the team investigates. This combination gives maximum safety with minimum deployment overhead.
Azure App Service Deployment Slots
Deployment slots implement blue-green deployment natively in Azure App Service:
- Production slot — serves live traffic
- Staging slot — receives the new deployment
- Swap operation — instantly switches which slot serves production traffic
- Auto-swap — automatically swap after deployment to staging succeeds
What swaps and what does not:
- Swapped: app code, app settings marked “not sticky”, connection strings marked “not sticky”, handler mappings
- NOT swapped (slot-sticky): settings marked as deployment slot settings, diagnostic settings, WebJobs, custom domain names, TLS/SSL certificates, scale settings
Slots share the same App Service plan. The slot itself has no extra compute cost, but it does consume resources from the plan.
Exam tip: Strategy selection decision tree
The exam presents scenarios and asks which strategy fits best. Use this decision tree:
- “Zero downtime AND instant rollback” → Blue-green (or deployment slots)
- “Validate with real users before full rollout” → Canary
- “Release to internal users first, then gradually expand” → Ring-based
- “Large fleet of stateless servers behind an LB” → Rolling
- “Compare business metrics between two versions” → A/B testing
- “Deploy code but control when users see features” → Feature flags
- “Minimise infrastructure cost while reducing risk” → Canary or rolling (avoid blue-green 2x cost)
- “Regulated environment needs audit trail of who saw what version” → Ring-based with user targeting
When two strategies seem to fit, look for the distinguishing detail in the scenario — cost concern, rollback speed requirement, or whether they are measuring business vs technical metrics.
Exam tip: Progressive exposure is the umbrella
Progressive exposure is not a separate strategy — it is the umbrella term for any approach that gradually exposes users to changes. Blue-green, canary, ring-based, and feature flags are all forms of progressive exposure. If the exam asks “which is an example of progressive exposure?” — all of them are correct. Pick the most specific answer if multiple options are progressive exposure techniques.
A SaaS company wants to release a new billing feature to 1% of users, monitor for errors for 24 hours, then expand to 10%, 50%, and finally 100%. If errors spike at any stage, they want to pull back within minutes. Which deployment strategy should they use?
Nadia needs to deploy a critical hotfix to Meridian's claims portal. The portal runs on Azure App Service. She needs zero downtime and the ability to roll back instantly if the fix causes issues. What should she use?
A product manager wants to test whether a new checkout flow increases conversion rates. The team should show the new flow to half of users and the old flow to the other half, then measure purchases. Which strategy is this?
🎬 Video coming soon
Deployment Strategies Deep Dive
Next up: Safe Rollouts: Slots, Dependencies and Hotfix Paths