6.4Rolling Deployment

How It Works

Instances are updated one at a time (or in small batches) across the fleet. At any given moment during the rollout, some instances run the old version and some run the new version.

Start:    [v2.3] [v2.3] [v2.3] [v2.3]
Step 1:   [v2.4] [v2.3] [v2.3] [v2.3]  ← Health check on v2.4
Step 2:   [v2.4] [v2.4] [v2.3] [v2.3]  ← Health check on v2.4
Step 3:   [v2.4] [v2.4] [v2.4] [v2.3]  ← Health check on v2.4
Step 4:   [v2.4] [v2.4] [v2.4] [v2.4]  ← Done

Where Tests Run

1. Before deployment: Standard test suite against staging
2. During rollout: Health checks on each updated instance before proceeding
3. After full rollout: Smoke tests against production

Risk Level: Medium

Mixed versions run simultaneously during the rollout. This can cause issues if the old and new versions have incompatible database schemas or API contracts.

QA Implications

• Tests must account for backward compatibility during the rollout window
• Health check endpoints must be meaningful (not just returning 200)
• Database migrations must be backward-compatible (expand-contract pattern)
• API versioning becomes important -- can old clients talk to new servers and vice versa?