Deployment Strategies
A deployment strategy determines how new code reaches production (Stage 10) and what happens if problems are detected.
For controlling when features reach users, see Release Toggling (Stage 12).
The following diagram compares the four primary deployment strategies, showing their processes, risk levels, and when to use each approach.
Strategy Comparison
| Strategy | Downtime | Rollback | Complexity | Cost | Best For |
|---|---|---|---|---|---|
| Hot Deploy | Brief (<30s) | 1-2 min | Low | Low | Internal tools, batch jobs |
| Rolling | None | ~5 min | Medium | Low | Standard web services |
| Blue-Green | None | Instant | Medium | High (2x) | High-risk deployments |
| Canary | None | Instant | High | Medium | Production validation |
Hot Deploy
Replaces running instances directly with brief service interruption.
Process: Stop instance → Replace files → Start instance → Verify health
Use when:
- Single-instance applications
- Brief downtime acceptable
- Fast-starting applications (<10s startup)
- Simple infrastructure
Avoid when: Zero downtime required, stateful sessions, high availability needed.
Variants: Prepare files in staging folder, switch host binding to minimize downtime.
Rolling Deployment
Updates instances gradually while others continue serving traffic.
Process: For each instance: Remove from LB → Update → Health check → Add back to LB
Use when:
- Multiple instances behind load balancer
- Zero downtime required
- Changes are backward-compatible
Avoid when: Single instance, breaking changes, database migrations requiring same version.
Blue-Green Deployment
Maintains two identical environments. Deploy to inactive, test, switch traffic.
Process: Deploy to Green → Test Green → Switch traffic Blue→Green → Blue becomes idle
Use when:
- Instant rollback critical
- Large artifacts or slow startup
- Database migrations need full testing
- High-stakes releases
Tradeoffs: Higher infrastructure cost (2x for some licensing), database state management complexity.
Canary Deployment
Routes small percentage of traffic to new version, monitors metrics, gradually increases.
Process: Deploy canary (1-5%) → Monitor metrics → Increase (10%→25%→50%→100%) or rollback
Use when:
- Need production validation before full rollout
- Have robust monitoring and metrics
- Large user base (1% is meaningful sample)
- Risk-averse organizations
Avoid when: Small user base, poor observability, breaking changes.
Key metrics: Error rate, P95 latency, conversion rate, user engagement.
Decision Framework
Can you tolerate any downtime?
- No → Rolling, Blue-Green, or Canary
- Yes (<30s) → Hot Deploy
Need instant rollback?
- Yes → Blue-Green or Canary
- No → Rolling or Hot Deploy
Have robust monitoring?
- Yes → Canary (metrics-driven)
- No → Blue-Green (instant switch)
External Resources
Next Steps
- Rollback Procedures - Emergency response
- Release Toggling - Feature flags and progressive exposure (Stage 12)
- CD Variants - RA vs CDe patterns
Tutorials | How-to Guides | Explanation | Reference
You are here: Explanation — understanding-oriented discussion that clarifies concepts.