Deployment: Blue-Green, Canary, Rolling and Feature Flags
Deployment strategy is the single most impactful decision for release risk. The right strategy minimizes user-facing impact when a new version introduces a bug, while the wrong strategy can turn a routine release into a production incident. Modern deployment strategies — rolling updates, blue-green deployments, canary releases, feature flags, and A/B testing — each offer different trade-offs between speed, risk, resource cost, and rollback complexity.
Rolling Updates
Rolling updates replace instances of the previous version with the new version gradually, one instance at a time or in batches. Kubernetes implements rolling updates natively through its Deployment controller; other orchestrators and load balancers support similar patterns.
How Rolling Updates Work
A rolling update incrementally replaces running instances while keeping the application available. In Kubernetes, the Deployment controller manages the process based on two parameters: maxSurge (how many extra instances can be created above the desired count) and maxUnavailable (how many instances can be unavailable during the update).
A typical rolling update with a desired replica count of 5 and default settings creates 1 new pod, waits for it to become healthy, terminates 1 old pod, and repeats until all pods run the new version. Throughout the process, at least 4 pods remain available.
When to Use Rolling Updates
Rolling updates are the best default choice for most production services. They require no additional infrastructure — the orchestrator handles everything — and consume no extra resources beyond the standard replica count. Rolling updates provide zero-downtime deployments when combined with proper health checks and graceful shutdown handling.
Risks and Limitations
No instant rollback. If the new version has a critical bug, rolling back requires another rolling update to replace the new version with the old version. During this time, the bug affects some users. Stateful applications — databases, message queues — may not support running multiple versions simultaneously. Rolling updates also expose partial deployment states where some users see the old version and others the new version, which can cause issues with API compatibility.
Blue-Green Deployments
Blue-green deployment maintains two identical production environments: “blue” (the current production version) and “green” (the new version). Traffic is switched from blue to green atomically at the load balancer or router level.
How Blue-Green Deployments Work
- The green environment is provisioned with the new version of the application.
- The CI/CD pipeline deploys to green and runs smoke tests against the green environment without exposing it to users.
- When green passes all checks, the load balancer or DNS is updated to route all production traffic to green.
- Blue remains running with the previous version for rapid rollback.
- After a stabilization period (hours or days), blue is decommissioned.
Cloud providers support blue-green at the service level. AWS Elastic Beanstalk environments can be swapped, Google Cloud Run supports revision traffic splitting, and Azure App Service supports deployment slots with swap operations.
When to Use Blue-Green
Blue-green deployments are ideal for applications where running two versions simultaneously is safe and the deployment risk is high. Database schemas that are backward-compatible enable safe blue-green deployments. The instant rollback capability — just switch traffic back to blue — is the strongest advantage.
Risks and Limitations
Double infrastructure cost. Two complete environments mean double the compute cost during the deployment window. For large infrastructure footprints (many instances, attached storage, cache clusters), this cost is significant. State compatibility is the primary failure mode. If the new version modifies a database schema that the old version cannot read, switching back to blue may fail. Blue-green deployments require backward-compatible database migrations or a migration strategy that separates schema changes from application deployments.
Canary Releases
Canary releases route a small percentage of traffic to the new version while the majority continues using the old version. Traffic is gradually increased as confidence grows, based on observed error rates, latency, and business metrics.
How Canary Releases Work
A canary release requires traffic routing infrastructure that can split requests by percentage. Service meshes (Istio, Linkerd), API gateways (Kong, Envoy), and cloud load balancers all support traffic splitting.
The typical canary progression:
- Deploy 1% of traffic to the new version. Monitor error rates, latency, and application-specific metrics for 10–30 minutes.
- If metrics are within baseline, increase to 5% and observe.
- Increase to 25%, then 50%, monitoring at each threshold.
- At 100%, the canary is fully rolled out. The old version is decommissioned.
Automated canary analysis tools — Argo Rollouts, Flagger, Spinnaker — manage the progression and trigger automatic rollback if metrics breach thresholds.
When to Use Canary Deployments
Canary releases are the safest deployment strategy for high-risk changes. They expose only a small user segment to potential issues, limiting blast radius. Canaries are standard practice for:
- Major architectural changes
- Performance-sensitive optimizations that could degrade user experience
- Machine learning model updates where behavior changes are unpredictable
- Regulatory environments requiring controlled exposure
Risks and Limitations
Complexity. Canary releases require traffic management infrastructure, monitoring instrumentation, and analysis automation. Teams without existing traffic-splitting capabilities face significant setup effort. Session affinity — requests from the same user must consistently route to the same version if sessions span multiple requests. Observability gaps can lead to false confidence if monitoring does not capture the relevant failure modes.
Feature Flags
Feature flags (also called feature toggles) decouple deployment from release. Code for a new feature is deployed to production but hidden behind a configuration flag. The flag is enabled for specific users, groups, or percentages without a new deployment.
How Feature Flags Work
A feature flag is a conditional check in the application code:
if (flags.isEnabled('new-checkout-flow', user.id)) {
return newCheckoutFlow();
--- else {
return legacyCheckoutFlow();
---Flag management platforms — LaunchDarkly, Split, Unleash, Flagsmith — provide dashboards for toggling flags in real-time without deployments. Flags support targeting rules: enable for internal testers, then 10% of users, then 50%, then 100%.
When to Use Feature Flags
Feature flags enable trunk-based development — developers merge incomplete features to the main branch without affecting users. Flags are essential for:
- Dark launches (deploy code that is not yet ready for users)
- Gradual rollouts with instant kill switch
- Per-environment configuration
- Beta programs with specific user segments
Risks and Limitations
Technical debt. Unused flags accumulate in code, creating dead code paths and testing overhead. Establish a flag lifecycle: every flag must have an owner, a review date, and a cleanup task after full rollout. Code complexity. Conditional checks scattered throughout the codebase make logic harder to follow and test. Use a centralized flag evaluation layer and clean up flags regularly.
A/B Testing Deployments
A/B testing deploys two or more variants of a feature simultaneously to measure which performs better against defined metrics. Unlike canary releases (which are about risk management), A/B testing is about optimization.
How A/B Testing Works
The deployment infrastructure routes users to variant A or variant B based on a consistent hash of user identity. The variants run in production, and analytics infrastructure collects user-level metrics — conversion rate, engagement, revenue. Statistical analysis determines whether the difference between variants is significant.
A/B testing is often combined with feature flags. LaunchDarkly and Split both support A/B testing workflows where flag targeting is driven by experiment assignments.
When to Use A/B Testing
Use A/B testing when the decision between two approaches is data-dependent — different UI layouts, pricing models, recommendation algorithms, or onboarding flows. A/B testing integrates with deployment strategies: deploy both variants, run the experiment, and when a winner is determined, deploy the winning variant to 100% and remove the loser.
Choosing a Strategy
| Strategy | Rollback Speed | Resource Cost | Complexity | Risk Level |
|---|---|---|---|---|
| Rolling update | Minutes | None | Minimal | Low to moderate |
| Blue-green | Seconds | 2× during transition | Moderate | Low |
| Canary | Automatic | 1–2× during transition | High | Lowest |
| Feature flags | Instant | None | Moderate (code complexity) | Low |
| A/B testing | N/A | 2× duration of experiment | High | Low |
Most production systems combine strategies. A typical pattern: feature flags for early access and kill switch, canary releases for staged traffic exposure, and blue-green deployments for major version upgrades that require infrastructure changes.
Frequently Asked Questions
Can I combine blue-green with canary?
Yes. Deploy to the green environment and then gradually shift traffic using load balancer weighting. This gives you the instant rollback capability of blue-green with the gradual exposure of canary. Spinnaker’s “canary with blue-green” strategy implements exactly this pattern.
What is the safest deployment strategy?
Canary releases are the safest for the end user because failures only affect a small traffic percentage. Feature flags are the safest for the developer because code can be toggled off instantly. The safest overall approach combines both: feature flags for instant kill switch with canary traffic progression for gradual exposure.
How do database migrations work with these strategies?
Database migrations must be backward-compatible. The old version must work correctly with the migrated schema because it remains running during rolling, blue-green, or canary deployments. Use additive migrations (new columns with defaults, new tables) and avoid destructive changes (column drops, renames) that break the old version.
Recommended Internal Links
- CI/CD Guide: Continuous Integration and Deployment Explained — foundational CI/CD concepts that deployment strategies build upon
- Container CI/CD: Docker, Kubernetes, and Container Registries — Kubernetes-native deployment strategies for containerized apps
- Release Management: Versioning, Changelogs, and Release Automation — release process coordination with deployment strategy
For a comprehensive overview, read our article on Artifact Management.
For a comprehensive overview, read our article on Ci Cd Best Practices.