What are deployment strategies?
A deployment strategy is how you replace the running version with a new one without breaking users. Rolling updates replace instances gradually, blue-green keeps two full environments and switches between them, and canary sends a small slice of traffic to the new version first.
Why it matters
Every deploy is a risk; the strategy decides how contained that risk is. A bad release with no strategy takes everyone down at once. With canary or blue-green, you catch problems on a fraction of traffic and roll back instantly. Shipping safely is a defining DevOps responsibility.
What to learn
- Rolling updates and gradual replacement
- Blue-green and instant switch/rollback
- Canary releases and progressive traffic shifting
- Health checks gating the rollout
- Automated rollback on error signals
- Database migrations alongside deploys
- Feature flags to separate deploy from release
Common pitfall
Shipping a backward-incompatible database migration in the same step as the code that needs it, during a rolling deploy. Old and new code run simultaneously mid-rollout, so one version hits a schema it does not expect. Make migrations backward-compatible and deploy them as a separate, earlier step.
Resources
Primary (free):
- Google Cloud — Deployment strategies · docs
- Martin Fowler — Blue-green deployment · article
- Martin Fowler — Canary release · article
Practice
Pick one service and write out how you would ship a change with a canary: what fraction of traffic goes to the new version first, what metric you watch, and what triggers an automatic rollback. Then describe how you would sequence a schema change safely. Done when the plan never has incompatible versions colliding.
Outcomes
- Compare rolling, blue-green, and canary strategies.
- Gate a rollout on health checks and metrics.
- Automate rollback on error signals.
- Sequence backward-compatible migrations around a deploy.