Deployment Strategies — 🚀 Rolling, Blue-Green, Canary

Deploying new code requires strategy to avoid downtime and minimize risk.

🎯 The Challenge

Bad deployment (no strategy):

1. Stop all servers
2. Deploy new code
3. Start all servers
Result: 5-10 minutes downtime (customers angry)

Good deployment (with strategy):

1. Deploy to 1 server while others run
2. Test new code
3. Gradually move traffic to new servers
Result: Zero downtime, instant rollback if problem

💡 Rolling Deployment

Deploy to one server at a time, gradually replacing all.

Before deployment:
[V1] [V1] [V1] [V1] (4 servers, version 1)

Step 1:
[V2] [V1] [V1] [V1] (1 new, 3 old)

Step 2:
[V2] [V2] [V1] [V1] (2 new, 2 old)

Step 3:
[V2] [V2] [V2] [V1] (3 new, 1 old)

Step 4:
[V2] [V2] [V2] [V2] (all new)

Pros:

• Zero downtime

• Gradual traffic shift

• Easy rollback (1-2 old servers still running)

• Minimal resources needed

Cons:

• Slow deployment (takes time)

• Briefly running two versions

• More complex to implement

🎨 Blue-Green Deployment

Two identical environments. Switch traffic from old to new instantly.

BLUE (Active)          GREEN (New)
[V1] [V1] [V1]        [V2] [V2] [V2]
  ↑                        ↑
  └─ Traffic routes ──────→ Switch to GREEN

After switch successful:
GREEN (Active)         BLUE (Standby)
[V2] [V2] [V2]        [V1] [V1] [V1]
  ↑
  └─ All traffic

Pros:

• Instant switch (no gradual rollout)

• Complete, identical environment to test

• Instant rollback (switch back to BLUE)

• Zero downtime

Cons:

• Requires 2x resources (expensive)

• More complex setup

• Data sync between environments

🎯 Canary Deployment

Deploy to small percentage of users first, expand if no problems.

Deployment:
├─ 1% of traffic → NEW version
└─ 99% of traffic → OLD version

Monitor for 10 minutes:
├─ Error rate normal?
├─ Response times okay?
└─ Customer issues?

If all good:
├─ 10% of traffic → NEW
├─ 50% of traffic → NEW
└─ 100% of traffic → NEW

If problem:
├─ Keep at 1%
├─ Investigate issue
└─ Rollback if needed

Pros:

• Real user testing in production

• Catches problems before wide rollout

• Gradual, low-risk

• Quick rollback if needed

Cons:

• Briefly serving two versions

• Requires good monitoring

• More complex

📊 Comparison Table

🎨 Real-World Choices

Netflix uses Canary

Deploy to 1% of servers first, monitor for hours, gradually expand to 100%.

GitHub uses Blue-Green

Maintain duplicate infrastructure, switch instantly.

Most companies use Rolling

Cost-effective, works well for gradual deploys.

🛠️ CI/CD Pipeline Integration

Modern deployment with automation:

Developer commits code
          ↓
Automated tests run
          ↓
Tests pass
          ↓
Deploy to canary (1% traffic)
          ↓
Monitor for errors
          ↓
No errors → Gradually expand to 100%
          ↓
Deployed! (fully automated)

🚨 Rollback Strategy

Always plan for rollback:

New version deployed → Error rate high
          ↓
Detect problem (1-2 minutes)
          ↓
Rollback initiated
          ↓
Traffic routes back to previous version
          ↓
Problem resolved (5-10 minutes impact)

🔑 Key Takeaways

• ✅ Rolling: Gradual deployment, minimal resources

• ✅ Blue-Green: Instant switch, requires 2x resources

• ✅ Canary: Real-world testing with 1% traffic first

• ✅ All achieve zero-downtime deployments

• ✅ Combine with automation (CI/CD) for best results

• ✅ Always plan rollback strategy

• ✅ Monitor closely during deployments

Want advanced patterns? 🚀 Deployment Strategies (Experienced)