Blue/Green Deployment

Blue/Green deployment reduces risk and downtime by running two production environments, Blue (current) and Green (new), with a router that switches all traffic from Blue to Green in one atomic operation.

Intent

Blue/Green deployment maintains two identical production environments — Blue (the currently live environment serving all traffic) and Green (the new version, fully deployed but receiving zero traffic). A router, typically a load balancer or Kubernetes service selector, performs the traffic switch: in a single atomic operation, all traffic moves from Blue to Green. Rollback is equally instant: switch the router back to Blue.

The defining characteristic is the 100% or 0% traffic split. Unlike Canary (which routes a percentage) or Rolling (which replaces instances gradually), Blue/Green gives no user a degraded experience during the transition. Either all users see the old version (Blue) or all users see the new version (Green). There is no overlap window during normal operation — only a very brief pre-switch coexistence period when both environments share the same database.

The lineage for this pattern traces through the deployment risk-reduction chain: Strategy-Pattern defines runtime variation → Feature-Flags-Pattern enables runtime toggles that validate Green before the router switch → Blue/Green deployment is the atomic cutover mechanism. Feature Flags are often used in the coexistence period to enable Green-side features only after the router has switched.

When NOT to Use

• Cost-constrained environments without ephemeral Green: Blue/Green requires double the infrastructure capacity. If spinning up and tearing down a Green environment per deployment is not feasible, the cost is prohibitive.
• Non-backward-compatible DB schema changes: Both environments share the same database during the pre-switch window. If Green's migration has already altered the schema in a way that breaks Blue, Blue starts throwing errors before the router switches. See the DB schema pitfall callout below.
• Stateful applications where session data cannot be shared: If sessions live in instance memory rather than an external store (Redis, DB), users on Blue lose state when the router switches mid-session.
• Simple low-risk changes where Rolling deployment is sufficient: Blue/Green overhead is unnecessary when there is no meaningful rollback risk.

When to Use

• High-risk changes requiring instant rollback capability: The switch-back to Blue is as fast as the switch-to-Green. Any degradation after cutover is recoverable in seconds.
• Compliance or audit requirements demanding clear environment separation: Blue and Green are isolated environments with full audit trails of what ran when.
• Zero-downtime deployments with atomic cutover: No gradual rollout window; no users are served by a mixed version state during normal operation.

How It Works

Before switch:
  [Router] ──► [Blue  (v1.2 — ACTIVE, 100% traffic)]
               [Green (v1.3 — IDLE, 0% traffic)]

After switch:
  [Router] ──► [Blue  (v1.2 — IDLE, 0% traffic)]
               [Green (v1.3 — ACTIVE, 100% traffic)]

Rollback:
  [Router] ──► [Blue  (v1.2 — RESTORED, 100% traffic)]
               [Green (v1.3 — IDLE, 0% traffic)]

Steps:

1. Deploy the new version to the idle Green environment.
2. Run smoke tests, health checks, and feature flag validation against Green (receives no production traffic yet).
3. Switch the router — all traffic atomically moves to Green.
4. Monitor for errors. If degradation detected, switch router back to Blue (instant rollback).
5. After confidence period, decommission Blue (or leave idle for the next deployment cycle).

The router is an infrastructure concern: AWS ALB target group swap, Kubernetes service selector update, or ELB listener rule change. The application is unaware of which color it is.

Pitfall — DB schema must be backward-compatible before cutover: Blue/Green requires both environments to share the same database during the brief pre-switch period. If Green's deployment pipeline runs a schema migration that drops or renames a column that Blue still reads, Blue throws errors immediately — before the router has switched. Apply the Expand/Contract pattern: (1) Expand — add new column without removing old; (2) switch router to Green; (3) Contract — remove old column after Blue is decommissioned. The schema must support both application versions simultaneously for the duration of the coexistence window.

Deployment Diagram

Blue-Green-Deployment-diagram.excalidraw

TypeScript Example

// Blue/Green Deployment — TypeScript (typed interface showing router contract)
// Source: Fowler, "BlueGreenDeployment", martinfowler.com
// The router is infrastructure (load balancer, Kubernetes service selector) — not application code.
 
interface BlueGreenRouter {
  activeEnvironment: 'blue' | 'green';
  // Atomic switch: all traffic moves to target environment in one operation.
  // DB schema MUST be backward-compatible before calling switchTo().
  switchTo(target: 'blue' | 'green'): Promise<void>;
  rollback(): Promise<void>; // restore previous environment
}
 
// DB SCHEMA RULE: before switchTo('green'), the database schema must support
// BOTH the blue (old) and green (new) application versions simultaneously.
// Use Expand/Contract migration pattern — never break old schema before switch.

Java Example

// Blue/Green Deployment — Java (typed interface showing router contract)
// Source: Fowler, "BlueGreenDeployment", martinfowler.com
// The router is infrastructure (load balancer, Kubernetes service selector) — not application code.
 
public interface BlueGreenRouter {
    Environment getActiveEnvironment(); // returns BLUE or GREEN
 
    // Atomic switch: all traffic moves to target environment in one operation.
    // DB schema MUST be backward-compatible before calling switchTo().
    void switchTo(Environment target) throws DeploymentException;
 
    void rollback() throws DeploymentException; // restore previous environment
}
 
// enum Environment { BLUE, GREEN }
// DB SCHEMA RULE: use Expand/Contract pattern — both app versions must read
// the database successfully during the pre-switch coexistence window.

Choosing a Release Strategy

Use this table to choose between Blue/Green, Canary, and Rolling deployment:

Lineage Backward

[[Strategy-Pattern]] → [[Feature-Flags-Pattern]] → Blue/Green Deployment

Lineage Forward

[[Deployment-Patterns-MOC]]

Related Concepts

Sources

• Fowler, Martin. "BlueGreenDeployment" — martinfowler.com/bliki/BlueGreenDeployment.html — original Blue/Green definition and DB constraint implications
• Kim, Humble, Debois, Willis. The DevOps Handbook, IT Revolution Press, 2016 — Blue/Green deployment in continuous delivery context
• AWS Blue/Green Deployment documentation — docs.aws.amazon.com/codedeploy/

Backlinks

Notes that link here: Feature-Flags-Pattern, Strategy-Pattern, Canary-Release-Pattern, Rolling-Deployment