How to ship changes safely using blue/green, canary, and feature flags.
How to ship changes safely using blue/green, canary, and feature flags.
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
Two identical environments. Switch 100% of traffic in one step. Instant rollback by flipping back.
Gradual rollout: send a small % of traffic to the new version, then increase. Catch issues before everyone is affected.
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
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.
Scenario: 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.
DevOps and release engineering: expect to compare deployment strategies and describe how you would safely ship a risky change.
Common questions:
Key takeaways
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.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.