Deployment Strategies: Changing the Engine Mid-Flight

[!TIP] The Goal: Deploy to production without the user noticing a single error.

In the old days, we had “Maintenance Windows” (Site down from 2 AM to 4 AM). Today, Netflix deploys thousands of times a day. How? They use advanced Deployment Strategies to minimize risk.

1. The Big Three Strategies

1.1 Rolling Update (Kubernetes Default)

  • Mechanism: Replace instances one by one.
    • Start 1 new pod (v2). Wait for it to be healthy.
    • Kill 1 old pod (v1).
    • Repeat until all are v2.
  • Pros: Zero downtime. Low cost (only need +1 capacity).
  • Cons: Slow rollback. Hard to debug (traffic hits both v1 and v2 simultaneously).

1.2 Blue/Green Deployment

  • Mechanism: Two identical environments.
    • Blue: Live (v1).
    • Green: Staging (v2).
    • Run tests on Green. When ready, switch Load Balancer from Blue -> Green.
  • Pros: Instant rollback (Switch back to Blue). No mixed versions.
  • Cons: Expensive (Need 2x resources).

1.3 Canary Deployment (The Safest)

  • Mechanism: Roll out v2 to a small subset of users (e.g., 1%).
    • Monitor metrics (Error Rate, Latency).
    • If healthy, increase to 10%, 50%, 100%.
    • If errors spike, rollback automatically.
  • Pros: Lowest risk. Real user testing.
  • Cons: Complex setup (Need advanced Load Balancer / Service Mesh).

Interactive Visualizer: Deployment Simulator

You are the Release Engineer. Deploy v2 to production. Careful! v2 might have bugs.

Canary Deployment Console

Traffic Split: 100% v1 / 0% v2

v1 (Stable)
v2 (New)
Error Rate (v1): 0.01%
Error Rate (v2): 0.00%
Adjust slider to shift traffic.

2. Feature Flags: Decoupling Deploy from Release

What if you want to deploy code but not show it to users yet?

Feature Flags (Toggles) allow you to wrap new code in an if statement:

if feature_flags.is_enabled("new_checkout_flow", user_id):
    render_new_checkout()
else:
    render_old_checkout()
  1. Deploy: Push code to production (Flag = False).
  2. Test: Enable flag for internal users (“dogfooding”).
  3. Release: Enable flag for 10% of users.
  4. Full Launch: Enable flag for 100%.

3. GitOps: Infrastructure as Code

GitOps (popularized by ArgoCD/Flux) means using a Git repository as the Single Source of Truth for your infrastructure.

  • Old Way: kubectl apply -f deployment.yaml (Manual, error-prone).
  • GitOps Way:
    1. Commit deployment.yaml to Git.
    2. ArgoCD sees the change in Git.
    3. ArgoCD syncs the cluster to match Git.

[!TIP] Why GitOps? Audit trail. Every change to production is a Git Commit. You can revert infrastructure changes just like code (git revert).

4. Summary

Strategy Speed Safety Cost Best For
Rolling Update Medium Medium Low Standard microservices.
Blue/Green Fast High High Critical legacy apps. DB migrations.
Canary Slow Highest Medium High-scale, user-facing apps.
Feature Flags Instant High Low UI changes, Dark Launches.

Next: Module Review ->