WSS
On this page
Deployment & DeliveryRequiredUpdated

Blue-green deployment

Blue-green deployment runs two identical production environments simultaneously. Only one serves live traffic at a time, allowing instant rollbacks by routing traffic back to the previous environment.

Introduction

Blue-green deployment is a release strategy that maintains two distinct, identical production environments. One environment (blue) runs the current application version and serves all live traffic. The other environment (green) runs the new version and receives no live traffic.

When the green environment passes all deployment checks, a load balancer or router switches all traffic from blue to green. Green becomes the new live environment. Blue remains idle, holding the previous version.

Mental Model

Think of a train switching tracks. Both tracks lead to the same destination. The train runs on Track A. Track B undergoes maintenance and testing. When Track B is ready, the switch moves. The train now runs on Track B instantly. Track A sits empty, ready in case Track B develops a fault.

Operational Pattern

The deployment pipeline pushes the new application version to the idle environment. Automated tests run against this environment to verify functionality without impacting users.

The traffic switch occurs at the routing layer. This involves updating a load balancer rule, modifying a DNS record, or reconfiguring a reverse proxy.

If the new version exhibits unexpected errors after the switch, the routing change reverts. Traffic returns to the original environment. This rollback takes seconds, avoiding the delays of a full redeployment process.

The previously live environment stays active for a defined period. Once confidence in the new version reaches an acceptable level, the pipeline destroys the old environment to save resources.

Failure Modes

Database schema changes break blue-green deployments. If the new version requires a schema change that is incompatible with the old version, the old version fails immediately after a rollback.

Stateful connections drop during the switch. Active WebSockets, long-running downloads, and sticky sessions terminate unless the router supports connection draining.

Running two full production environments doubles infrastructure costs. This makes blue-green deployment expensive for large, monolithic applications with high resource requirements.

Security

Both environments require identical security controls. A vulnerability in the idle environment still exposes the infrastructure.

Isolate the environments at the network level. The green environment must not inadvertently connect to external services using the blue environment’s identity.

Limit access to the routing switch. The ability to flip traffic between environments requires strict access control and auditing.

Operational Guidance

Decouple database migrations from application deployments. Apply schema changes in a backward-compatible manner before deploying the application code. Ensure both the blue and green versions function correctly with the modified database.

Implement connection draining at the load balancer. Give active requests time to complete on the old environment before terminating the instances.

Automate the traffic switch. Manual intervention introduces delays and human error during critical release windows.

Diagnostics

Monitor error rates immediately after the traffic switch. A spike in HTTP 500 errors indicates a failed deployment requiring immediate rollback.

Track the time taken to complete the traffic switch. A switch that takes minutes rather than seconds indicates an inefficient routing configuration.

Compare resource utilization between the active and idle environments before the switch. Significant discrepancies point to configuration drift.

Related topics

Sources & further reading