Deployment strategies
How to ship changes safely using blue/green, canary, and feature flags.
Deployment strategies
How to ship changes safely using blue/green, canary, and feature flags.
What you'll learn
- Blue/green: two environments, switch traffic in one step; instant rollback.
- Canary: gradual rollout (e.g. 1% → 100%); good for risky or data-sensitive changes.
- Feature flags let you deploy code behind a toggle and enable for subsets of users.
Blue/green vs canary vs rolling
Blue/green deployments run two production environments side by side. You switch 100% of traffic from blue to green in one step, with instant rollback by flipping back.
Canary releases roll out gradually: start with 1–5% of users, then 25%, then 100%. This is safer for changes that might behave differently under real traffic or data.
Rolling deployments replace instances one by one (or in batches). Old and new versions run together during the rollout-no second full environment needed. Feature flags let you deploy code behind a toggle and turn it on for a subset of users without a new release.
How deployment strategies control traffic
Blue/Green
Two identical environments. Switch 100% of traffic in one step. Instant rollback by flipping back.
- ✓ Instant switch, fastest rollback
- ! Requires 2× production capacity
Canary
Gradual rollout: send a small % of traffic to the new version, then increase. Catch issues before everyone is affected.
- ✓ Safest for risky changes
- ! Slower full rollout
Rolling
Replace instances one by one (or in small batches). No second full environment; old and new versions run together during the rollout.
Old and new coexist during rollout; no 2× capacity needed
Feature flags
Deploy code behind a toggle. Turn the feature on for a subset of users (or 100%) without a new deployment. Combine with canary or blue/green for maximum control.
Real-world scenario: risky database migration
Expert scenarioScenario: You are deploying a large database schema change for user data.
Decision: A pure blue/green switch can cause data divergence if users write to both schemas. A safer approach is a canary rollout combined with backward-compatible migrations and feature flags. If errors spike for the first 1% of users, you disable the flag and roll back without impacting everyone.
How this might come up in interviews
DevOps and release engineering: expect to compare deployment strategies and describe how you would safely ship a risky change.
Common questions:
- When would you use blue/green vs canary vs rolling?
- How do you roll back a bad deployment?
- What are feature flags and when do you use them?
Key takeaways
- Blue/green: two environments, switch traffic in one step; instant rollback.
- Canary: gradual rollout (e.g. 1% → 100%); good for risky or data-sensitive changes.
- Feature flags let you deploy code behind a toggle and enable for subsets of users.
Before you move on: can you answer these?
When would you choose canary over blue/green?
When the change might behave differently under real traffic or data; canary lets you detect problems with a small subset before full rollout.
From the books
The Phoenix Project
Ch. 18–19
Deployments that are risky and infrequent create a vicious cycle. Safe, frequent releases reduce the batch size of change and make the system easier to fix when something goes wrong.
Related concepts
Explore topics that connect to this one.
Practice with these scenarios
Apply this concept in hands-on scenarios.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Discussion
Questions? Discuss in the community or start a thread below.
Join DiscordIn-app Q&A
Sign in to start or join a thread.