Blue-Green Deployment Pattern

Blue-green deployment keeps two identical production environments. One is live, the other idle or staging the next release. The release becomes a routing decision instead of a risky in-place mutation, which turns rollback into a fast and well-rehearsed action.

How it works

Blue serves all customer traffic while green is provisioned from the same infrastructure definition and receives the new build. Automated smoke tests, synthetic transactions, and health checks run against green using internal routing. When the checks pass, the load balancer target group or DNS weight changes so that green becomes live. Blue is retained, untouched, as the rollback target until a soak period completes, after which it becomes the staging area for the next release.

Implementation steps

1. Define infrastructure as code so both environments are provably identical
2. Deploy the new version to the idle environment and run migrations in an expand-only mode
3. Execute smoke tests, contract tests, and synthetic user journeys against the idle side
4. Drain connections on the live side and switch the router to the new environment
5. Monitor error rate and latency during a soak period before retiring the old version
6. Contract the schema only after the old version is permanently gone

Common pitfalls

• Treating the database as part of the environment; both versions must work with one schema at the switch
• Caches, queues, and scheduled jobs running twice or not at all after the switch
• DNS based switching with long TTLs causing slow or uneven cutover
• Forgetting to keep the idle environment patched and in sync, so it drifts

Metrics to watch

• Error rate and p99 latency before and after the switch
• Time to switch and time to roll back
• Number of failed pre-switch verification runs
• Cost of idle capacity per release
• Percentage of releases requiring rollback

Example configuration

# Kubernetes service selector flip
apiVersion: v1
kind: Service
metadata:
  name: checkout
spec:
  selector:
    app: checkout
    track: green   # change from blue to cut over
  ports:
    - port: 80
      targetPort: 8080

Trade-offs and adoption

Teams adopt this approach when releases need near-instant rollback; the application is stateless or its state is shared and backward compatible. It is a poor fit when database schema changes are destructive and cannot be made backward compatible, or when infrastructure cost of a duplicate environment is prohibitive. The central tensions are rollback speed vs infrastructure cost; release simplicity vs blast radius; environment parity vs operational overhead. The main benefits are that it delivers: rollback is a routing change rather than a redeploy; full pre-release verification in the real production topology; no mixed-version traffic during normal operation; simple mental model for operators and auditors. The main costs to budget for are: doubles infrastructure during the release window; shared databases require careful expand-and-contract migrations; all users switch at once, so blast radius is total; in-flight requests and sessions need explicit draining. Governance typically looks like this: release owner approves the traffic switch after automated verification gates. Expect adoption cost to be medium: duplicate environments and routing automation, and a best fit for small to large teams with automated infrastructure. Critics point out that shared databases undermine the isolation the pattern promises, and that the big-bang switch gives no gradual exposure to detect subtle regressions. Treat these concerns as design inputs, and revisit the decision as traffic, team size, and failure history change.

Key takeaways

• Make the release a routing change, not a redeploy
• Backward compatible schema changes are the hard part
• Keep the old environment warm until the soak completes
• Pair with canary releases when total blast radius is unacceptable