When should you NOT use Blue/Green Deployment?

Avoid blue-green when your database schema changes are not backward-compatible — both environments share state and the old app may break on a new schema. Do not use it for services where running two versions simultaneously causes correctness issues (e.g. exclusive queue consumers).

When is Blue/Green Deployment the right choice?

Use blue-green when you need instant rollback — switching traffic back is a single load-balancer change, not a re-deploy. Apply it when the cost of downtime exceeds the cost of running two identical environments simultaneously. Combine with smoke tests against the green environment before flipping traffic — the idle environment is a free staging slot.

← Back to glossary

Blue/Green Deployment

DevOps PHP 5.0+ Intermediate

debt(d7/e7/b5/t7)

d7 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'only careful code review or runtime testing' (d7). The detection_hints indicate automated detection is 'no', and the code_pattern describes symptoms like downtime, missing rollback capability, and absent smoke tests — none of which surface until deployment time or post-incident review. Tools listed (aws-codedeploy, kubernetes, capistrano) help implement the pattern but do not detect misuse of it. Misconfigurations like un-warmed environments or misrouted background workers only manifest under production load.

e7 Effort Remediation debt — work required to fix once spotted

Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix describes maintaining two full production environments, updating load balancer configuration, establishing smoke test pipelines, and coordinating database migration strategies. Common mistakes reveal that background workers, caches, and migrations all need independent remediation. Fixing an improperly implemented blue-green deployment touches infrastructure, deployment scripts, CI/CD pipelines, and database migration procedures — a cross-cutting concern well beyond a single-component fix.

b5 Burden Structural debt — long-term weight of choosing wrong

Closest to 'persistent productivity tax' (b5). The applies_to scope covers web and API contexts broadly, and maintaining two identical production environments imposes ongoing operational overhead on every deployment cycle. Teams must coordinate environment warm-up, migration timing, and worker routing on every release. It doesn't fully reshape the system's architecture (b7), but it does create a persistent tax on multiple workflows including deployments, migrations, and monitoring.

t7 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'serious trap' (t7). The misconception field directly states the canonical wrong belief: developers assume blue-green eliminates all deployment risk, but data migrations in the green environment affect production data immediately and cannot be rolled back by a traffic switch alone. This directly contradicts the widely-held mental model that 'instant rollback' means full safety — a competent developer familiar with the zero-downtime pitch will naturally assume rollback undoes all effects, which is wrong in the data layer.

About DEBT scoring → scored by claude-sonnet-4-6 · 2026-05-06 · reviewed by human

Also Known As

blue-green deploy blue green strategy zero-downtime blue green

TL;DR

Maintaining two identical production environments and switching traffic between them for zero-downtime releases and instant rollback.

Explanation

Blue/Green deployment keeps two production-identical environments. The live environment (say, blue) serves all traffic while the new release is deployed to the idle environment (green) and tested. Traffic is switched (via load balancer or DNS) from blue to green instantaneously. If issues arise, switching back to blue provides immediate rollback. The main costs are double infrastructure and the challenge of shared state (database migrations must be backward compatible with both versions during switchover). Blue/Green is distinct from canary releases, which gradually shift a percentage of traffic.

Diagram

flowchart LR
    LB[Load Balancer] -->|100% traffic| BLUE[Blue<br/>v1.2 LIVE]
    LB -.->|0% traffic| GREEN[Green<br/>v1.3 IDLE]
    subgraph After Deploy
        LB2[Load Balancer] -->|100% traffic| GREEN2[Green<br/>v1.3 LIVE]
        LB2 -.->|0% fallback| BLUE2[Blue<br/>v1.2 STANDBY]
    end
style BLUE fill:#1f6feb,color:#fff
style GREEN fill:#238636,color:#fff

Watch Out

⚠ Blue-green does not solve database migrations — if the new code requires a column that does not exist yet, the green environment crashes on startup. Always expand-then-migrate: add the column first, deploy, then drop the old one.

Common Misconception

✗ Blue-green deployment eliminates all deployment risk. Blue-green eliminates downtime and enables instant rollback, but the new version runs against real production data — a data migration bug in the green environment affects production immediately and cannot be rolled back by switching traffic alone.

Why It Matters

Blue-green deployment gives you instant, zero-downtime rollback — if the new version has a critical bug, you flip the load balancer back to the previous environment in seconds rather than scrambling to redeploy.

Common Mistakes

Running database migrations before switching traffic — if the migration breaks, rollback is now impossible without data loss.
Not keeping both environments warm — a cold "green" environment has cache misses and slower initial responses.
Forgetting to update background workers when switching — jobs may still be routed to the old environment.
Treating blue-green as a substitute for testing — it reduces recovery time, it does not replace pre-deployment validation.

Avoid When

Avoid blue-green when your database schema changes are not backward-compatible — both environments share state and the old app may break on a new schema.
Do not use it for services where running two versions simultaneously causes correctness issues (e.g. exclusive queue consumers).

When To Use

Use blue-green when you need instant rollback — switching traffic back is a single load-balancer change, not a re-deploy.
Apply it when the cost of downtime exceeds the cost of running two identical environments simultaneously.
Combine with smoke tests against the green environment before flipping traffic — the idle environment is a free staging slot.

Code Examples

💡 NoteThe bad deploy stops the server, deploys, and restarts — causing downtime. The fix deploys to the idle green environment, runs health checks, then flips the load balancer with zero user-visible interruption.

✗ Vulnerable

// Single environment deploy — downtime during swap:
// 1. Stop app server
// 2. Deploy new code
// 3. Restart app server  <- downtime window here
// 4. Test (on live traffic)

// Blue-green: no downtime:
// 1. Deploy to green (idle environment)
// 2. Test green
// 3. Switch load balancer from blue to green — instant, zero downtime
// 4. Keep blue as instant rollback

✓ Fixed

# Blue = current live, Green = new version
# 1. Deploy new version to Green environment (zero traffic)
nginx -s reload  # after updating upstream to green

# 2. Smoke test Green
curl https://green.internal/health

# 3. Switch load balancer to Green
# nginx upstream config:
upstream app {
    # server blue-app:9000;  ← comment out
    server green-app:9000;   # ← activate
}

# 4. Monitor — rollback in seconds by reversing the upstream swap
# 5. Decommission Blue after confidence period

References

https://martinfowler.com/bliki/BlueGreenDeployment.html