Gyaan

Deployment Strategies

intermediate deployment blue-green canary rolling

Deploying code is the scariest part of software development. We’ve all seen “we’re deploying, fingers crossed” in Slack. Good deployment strategies take the fear out of shipping by giving us safe ways to roll out changes — and safe ways to roll them back.

Rolling Update

The most common strategy. We replace instances one at a time (or a few at a time). At any point during the deploy, some instances run the old version and some run the new one.

Think of it like replacing tires on a moving bus — one at a time, so the bus never stops.

  • Zero downtime
  • Simple to set up (default in Kubernetes)
  • Rollback by continuing to roll — but with the old version

The catch: for a brief period, both versions are live. If v2 changes the API or database schema, v1 instances might break.

Blue-Green Deployment

We run two identical environments — Blue (current) and Green (new). All traffic goes to Blue. We deploy to Green, test it, then flip the load balancer to point at Green.

Blue-Green Deployment
Before switch:
  Users → Load Balancer → Blue (v1) ✅ LIVE
                                    Green (v2) 🧪 testing
After switch:
  Users → Load Balancer → Green (v2) ✅ LIVE
                                    Blue (v1) standby
Rollback = flip the switch back to Blue. Instant.

The big win: rollback is instant — just switch traffic back. The downside: we need double the infrastructure (and cost).

Canary Deployment

We route a small percentage of traffic (say 5%) to the new version and watch the metrics. If error rates stay normal, we gradually increase to 100%.

Think of it like the “canary in a coal mine” — if the canary (small traffic slice) dies, we pull back before it affects everyone.

# Conceptual traffic split — usually handled by a service mesh or ingress
# Step 1: 5% to v2
# Step 2: watch error rates, latency, logs for 15 minutes
# Step 3: if healthy, bump to 25%, then 50%, then 100%
# Step 4: if something's wrong, route 100% back to v1

This is the safest strategy for large-scale systems. But it needs good observability (metrics, logs, alerts) to detect problems in that 5%.

Comparison At a Glance

Strategy Trade-offs
Rolling      — Simple, zero downtime, slow rollback
Blue-Green  — Instant rollback, double the cost
Canary      — Safest, needs good monitoring
Recreate    — Kill old, start new. Has downtime. Only for dev/staging.

Feature Flags: The Missing Piece

Feature flags let us deploy code without activating it. We ship the feature behind a flag, enable it for 1% of users, and watch. If it’s broken, we toggle the flag off — no redeploy needed.

# Conceptual — most teams use LaunchDarkly, Unleash, or a simple env var
if FEATURE_NEW_CHECKOUT == "true":
    show_new_checkout()
else:
    show_old_checkout()

In simple language, deployment strategies are about one thing: how much risk are we comfortable with? Rolling is the default. Blue-green is for when we need instant rollback. Canary is for when we need proof the new version works before committing.

References