Zero-Downtime Deployments: Blue-Green, Canary and Rolling Release Strategies
How to deploy without downtime: rolling, blue-green and canary releases, feature flags, health checks, expand and contract migrations, and rollback.
How do you deploy without downtime?
Run the new version alongside the old one, send traffic to it only when health checks pass, shift traffic gradually (rolling or canary) or all at once with an instant switch back (blue-green), keep database changes backwards compatible with an expand and contract approach, drain connections cleanly, and watch error rates and key journeys so you can roll back quickly. Feature flags then separate releasing features from deploying code.
This guide is for developers and engineering leads. It builds on DevOps for growing businesses and feature flag implementation.
Key takeaways
- Readiness checks before traffic; graceful shutdown after.
- Choose rolling, blue-green or canary per service and risk.
- Database changes must work with old and new code.
- Define automatic rollback triggers.
- Keep APIs compatible with older clients.
Strategies compared
| Strategy | How it works | Good for | Trade-off |
|---|---|---|---|
| Rolling | Replace instances gradually | Most stateless services | Old and new run together briefly |
| Blue-green | Two environments; switch traffic at once | Fast, clean rollback | Double capacity during release |
| Canary | Small share of traffic first, then more | High-risk changes, large user bases | Needs good metrics and routing |
| Feature flags | Deploy dark, enable gradually | Separating release from deploy | Flag clean-up and testing |
Mechanics that make it work
- Readiness and liveness checks so traffic only reaches ready instances; see the Kubernetes Deployment documentation (Kubernetes).
- Graceful shutdown and connection draining so in-flight requests finish.
- Stateless services with sessions in a shared store.
- Backwards-compatible APIs and message formats during the overlap.
- Automated smoke tests after each step.
- Rollback triggers on error rate, latency and key business events.
Database migrations: expand and contract
Most downtime comes from schema changes. Expand first: add new columns or tables without breaking old code. Deploy code that works with both. Backfill data in batches. Switch reads to the new structure. Contract later: remove old columns once nothing uses them. Check that migrations do not take long locks on large tables, and test them on production-sized data. See database performance optimisation.
Blue-green and canary in practice
Blue-green suits services where a quick full switch and instant rollback matter, as described by Martin Fowler (BlueGreenDeployment). Canary suits risky changes with enough traffic to detect problems early (CanaryRelease). For both, compare the new version's error rate, latency and business metrics, such as checkout completion, with the old version before going further. See monitoring and observability.
Hypothetical example: an ecommerce API
This example is hypothetical. An online retailer's deployments caused short outages and occasional failed checkouts. The team added readiness checks and graceful shutdown, moved to rolling deployments for most services and canary releases for the checkout API with automatic rollback on error rate, and adopted expand and contract for schema changes. A column rename that previously needed a maintenance window was done over three releases.
Common mistakes
- Readiness checks that always pass.
- Schema changes that break the running version.
- No rollback plan for data changes.
- Canary releases without metrics to judge them.
- Breaking API changes for older mobile app versions.
Related guides
- Kubernetes vs serverless vs VMs for platform choice.
- Automated regression testing for release confidence.
- Infrastructure as code for reproducible environments.
- Mobile app maintenance for staged app releases.
Conclusion
Zero-downtime deployment is a set of habits: health checks, graceful shutdown, gradual or switchable traffic, backwards-compatible data changes and quick rollback. Pick the strategy that matches each service's risk, measure releases, and use feature flags to separate deploy from release. To decide when to pause releases, see SLOs and error budgets.
Releases causing outages?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on web applications and release pipelines and mobile apps. If it would help to review how your software is released, we are happy to talk it through.
Common questions.
Blue-green runs two full environments and switches all traffic from the old (blue) to the new (green) at once, keeping blue ready for rollback. Canary sends a small share of traffic to the new version first, watches metrics, then increases gradually.