Blue-Green Deployment

Blue-green deployment maintains two production environments so the team can prepare a release in one while the other serves traffic. In the basic cutover, new traffic moves to the prepared environment and the previous environment remains available for recovery. This reduces the work required at the moment of exposure.

Martin Fowler’s description starts with final testing in the idle green environment, then switches incoming requests from blue to green. Returning traffic to blue can be fast if blue remains ready and can operate against the current state. Existing requests may continue on blue while new ones enter green; their completion and shutdown need an explicit drain policy.

Once the new version is stable and the agreed rollback window closes, the old environment can become the staging location for the next release. The environments alternate roles across releases. Reusing the old environment also removes that particular warm rollback target, so make the retention decision explicit.

What it gives you, and what it does not

A release cutover rehearses the routing and standby path it actually uses. Fowler relates that mechanism to disaster recovery, but the coverage depends on the design. Two application environments sharing a database do not exercise recovery from database loss, corruption, or a regional failure. Count the cutover toward DR evidence only for matching resources and failure scenarios; separately test the remaining recovery paths against recovery-time and data-loss objectives.

A traffic switch does not undo orders, messages, or data changes already produced. Fowler discusses synchronizing transactions to the standby or using a read-only interval during cutover. Either requires a design for the relevant state and operations. Retaining a warm application environment is useful only if it can still handle current data and interfaces.

Which leads to the question to settle before adopting it, because a fast switch is worth little if the state has moved on.

• Sessions. Shared session storage can preserve state across the switch, but both versions must understand its format and use compatible cookie and encryption settings. Process-local sessions can be lost when their old instances stop receiving the user’s requests unless another continuity mechanism exists.
• Work in flight. Stop assigning new work to the old environment, direct new work to the new one, then let existing work drain before shutting the old environment down. Set a timeout and specify retry, checkpoint, or reconnection behavior for unfinished work. HTTP requests, long-lived connections, background workers, and consumers need their own admission and shutdown controls. Argo Rollouts can delay scaling down the previous ReplicaSet after a switch; this allows traffic routing to settle but does not by itself guarantee that every application task has drained.
• Shared state. Whatever both environments write to is the thing that cannot be switched back — normally the database, and often a message broker or a cache.

The database is the whole difficulty

A common variation shares one database between the blue and green application environments. Both versions must then tolerate its schema and the data each version writes. A fast application switch cannot reverse a destructive database migration.

Expand the schema to support both versions, verify that existing access paths still work, and then deploy code that uses the new representation. Retain support for the previous version through the rollback window. Only after consumers have migrated and that window closes should the old representation be removed. The requirement is ordered, separately verified steps; a pipeline can coordinate them without making them simultaneous.

That is expand and contract stated for schemas, and it is the precondition that makes the router switch meaningful. Skip it and the second half of the promise disappears: the traffic switch still takes seconds, and the previous version no longer starts. Fast reversal of the application is not reversal of the system.

Compared with a canary, and what to run

Blue-green emphasizes prepared environments and rapid traffic switching; canary deployment emphasizes limited exposure and observation before expansion. Fast reversal depends on retained capacity, routing control, and state compatibility, not on which name the strategy uses. For example, Argo Rollouts abort can stop a rollout and reactivate its previous ReplicaSet with one command. Its desired template remains the new version until separately reverted. Neither strategy alone promises atomic recovery across an entire estate of services.

The two combine well and the combination is common in practice: route a small share of traffic to the new environment first, then move the rest and keep the old one warm as the reversal target. What is not optional in either case is the compatibility work, since both rely on old and new coexisting.

The cost depends on what is duplicated. Fowler describes separate machines, virtual machines on shared or separate hardware, and partitions within one operating environment. Those arrangements have different capacity and failure-isolation properties. The traffic switch may happen at a router or another entry point. Budget for the capacity needed while both environments are ready, and identify which dependencies remain shared.

Reversal here is rollback with a fast mechanism attached, and it carries the same precondition: the previous version has to be able to run against current data. How that precondition gets designed, and what to do when it fails, is worked through in Two Versions at Once.

References

• Martin Fowler, Blue Green Deployment
• Argo Rollouts, Rollout Specification
• Argo Rollouts, Abort
• Google SRE, Canarying Releases