🔵🟢 Blue-Green Deployment

Why Deployment Strategies Matter

A deployment strategy is simply how you replace the running version of your app with a new one. The naïve approach — stop the old version, start the new one — leaves a window where nobody can use the site. For a hobby project that might be fine. For an e-commerce checkout, every minute of downtime is lost revenue and lost trust.

Modern strategies exist to shrink that window to zero. The three you'll study this week each make a different trade-off between speed, cost, and risk:

This lesson focuses on blue-green: the cleanest mental model and the easiest to reason about, because at any moment every user sees exactly one version.

How Blue-Green Works

You run two identical production environments, named "Blue" and "Green." They are identical in every way — same infrastructure, same configuration, same scale — except for the version of the application code they run. Only one is live (serving real users) at a time; the other is idle, ready to become the next live environment.

The lifecycle of one release looks like this:

The key ideas

• Identical environments. The only difference is the app version. Keep them in sync with the same infrastructure-as-code so there is no "works on Blue but not Green" surprise.
• A switch in front. A load balancer, router, or DNS record decides which environment is live. Changing that one setting redirects everyone.
• Atomic cutover. Traffic moves all at once. No user ever gets a mix of old and new — a huge simplification compared to strategies where versions overlap.
• Instant rollback. The old environment is still running. If the new one misbehaves, flip the switch back.
• Shared backing services. Databases, queues, and caches are usually shared, which is exactly where the hard parts live (covered below).

The Traffic Switch & Rollback

"Flip the switch" can mean different things depending on where the switch lives. Each level trades simplicity for speed.

Rollback is the whole point

The reason blue-green feels safe is that a rollback is the same operation as the deploy, just aimed the other way. There is no rebuild, no re-deploy, no waiting — the previous version is still warm and running.

# Cut over to Green (make it live)
aws elbv2 modify-listener \
  --listener-arn "$LISTENER_ARN" \
  --default-actions Type=forward,TargetGroupArn="$GREEN_TG_ARN"

# Something's wrong? Roll back instantly by pointing at Blue again.
aws elbv2 modify-listener \
  --listener-arn "$LISTENER_ARN" \
  --default-actions Type=forward,TargetGroupArn="$BLUE_TG_ARN"

Database Migrations: The Hard Part

Here's the catch that trips up every newcomer: Blue and Green usually share one database. You can flip application code atomically, but you cannot keep two copies of your users' live data in sync. So the schema must work with both versions of the app during the switch and rollback window.

The expand-contract pattern

Never make a breaking change in one step. Split it across multiple deploys so that at every moment, the live schema is compatible with the code that could be running:

1. Expand. Add the new column/table alongside the old. Both versions of the app can now read the database.
2. Migrate & deploy. Ship the new code that writes to both old and new, and backfill existing rows in the background.
3. Contract. Only after the new version is proven stable (and rollback is no longer needed) do you drop the old column in a later release.

-- STEP 1 (Expand): additive change, safe for both app versions
ALTER TABLE users ADD COLUMN phone_number VARCHAR(20);
-- Old code never touches this column, so it keeps working.

-- STEP 3 (Contract): only in a FUTURE release, after v1.1 is trusted
-- ALTER TABLE users DROP COLUMN legacy_phone;

During the transition, the application writes to both fields so a rollback to the old code still finds the data it expects:

// Transitional write path (runs in the new version)
async function updateUserPhone(userId, phone) {
  const updates = { legacy_phone: phone };   // keep the old column populated...

  // ...and also fill the new column when the schema has it.
  if (await columnExists('users', 'phone_number')) {
    updates.phone_number = phone;
  }

  await db.update('users', userId, updates);
}

Handling State & Sessions

If your app keeps user sessions in the memory of a specific server, switching environments logs everyone out — their session lived on Blue, and Blue is no longer serving them. The fix is to externalize state so it survives the cutover.

// Sessions in Redis survive the blue-green switch because BOTH
// environments read from the same store — not from local memory.
import express from 'express';
import session from 'express-session';
import { RedisStore } from 'connect-redis';
import { createClient } from 'redis';

const app = express();
const redisClient = createClient({ url: process.env.REDIS_URL });
await redisClient.connect();

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: { secure: process.env.NODE_ENV === 'production', maxAge: 86400000 } // 1 day
}));

// A user logged in on Blue stays logged in on Green — the cookie
// points at a session that lives in shared Redis, not on any one box.
app.get('/profile', (req, res) => {
  if (!req.session.user) return res.redirect('/login');
  res.json({ user: req.session.user });
});

A Real Kubernetes Switch

In Kubernetes the "switch" is a Service selector. A Service routes to whichever Pods match its label selector, so changing one label — version: blue to version: green — instantly moves all traffic.

# The Service is the switch. Its selector decides which Deployment is live.
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    version: blue      # flip to "green" to cut over
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
spec:
  replicas: 3
  selector:
    matchLabels: { app: my-app, version: green }
  template:
    metadata:
      labels: { app: my-app, version: green }
    spec:
      containers:
        - name: my-app
          image: my-app:1.1
          ports:
            - containerPort: 8080
          readinessProbe:          # gate: no traffic until this passes
            httpGet: { path: /health, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 5

A safe cutover script deploys Green, waits for it to be healthy, smoke-tests it, then flips the selector — with a built-in rollback if the switch doesn't take:

#!/usr/bin/env bash
set -euo pipefail

# 1. Roll out the green version and wait until every pod is ready.
kubectl apply -f deployment-green.yaml
kubectl rollout status deployment/my-app-green --timeout=120s

# 2. Smoke-test green privately BEFORE it takes live traffic.
if ! kubectl run smoke --rm -i --restart=Never --image=curlimages/curl -- \
      -sf http://my-app-green/health; then
  echo "Green failed its health check — aborting, blue stays live."
  exit 1
fi

# 3. Flip the switch: point the Service at green.
kubectl patch service my-app -p '{"spec":{"selector":{"version":"green"}}}'
echo "Traffic switched to green."

# 4. Verify, and roll back automatically if green isn't serving v1.1.
sleep 10
if ! curl -sf http://my-app/version | grep -q '1.1'; then
  echo "Live traffic not reaching green — rolling back to blue."
  kubectl patch service my-app -p '{"spec":{"selector":{"version":"blue"}}}'
  exit 1
fi

echo "Deployment healthy. Keeping blue warm for the bake period."

Practice & Quiz

Best Practices & Pitfalls

✅ Do

• Keep Blue and Green truly identical using infrastructure-as-code
• Gate the switch on a deep health check that verifies real dependencies
• Use expand-contract so every migration is backward-compatible
• Externalize sessions, cache, and jobs so app servers stay stateless
• Keep the old environment warm for a bake period before scaling it down
• Automate both the switch and the rollback — never do the cutover by hand

❌ Don't

• Don't rely on DNS for an instant cutover — TTL caching causes mixed traffic
• Don't drop columns or make breaking schema changes in the switch release
• Don't tear down Blue the moment Green goes live — you lose your instant rollback
• Don't let configuration drift between the two environments
• Don't ship a "started = healthy" probe that lets traffic hit a half-ready app

Summary

📚 Additional Resources

• AWS — Blue-green deployments overview
• Google Cloud — Application deployment and testing strategies
• Kubernetes — Service (the routing switch)

🚀 What's Next?

Blue-green flips everyone at once. But what if you want to test a new version on just a sliver of real users first, watching the metrics before committing? That gradual, risk-minimizing approach is the next lesson: Canary Releases.