Common Deployment Strategies: Blue‑Green, Rolling, Canary (Gray) Release and A/B Testing

01. Blue‑Green Release

In a blue‑green deployment there are two complete environments: the currently serving (green) version and the new version (blue). Both are fully functional; the blue environment is used for pre‑release testing and, once validated, traffic is switched to it, allowing an easy rollback to green if needed.

The blue system is not exposed to users during testing, so any issues can be fixed without affecting live traffic. After a period of observation, the blue system becomes the new green system and the old green system can be decommissioned.

Blue‑Green Release Characteristics

Reduces downtime during release and enables rapid rollback.

Requires the two environments to be completely decoupled to avoid interference.

Blue‑Green Release Precautions

Not a universal solution; works best for tightly‑coupled services.

Database migration must be carefully planned.

Needs supporting infrastructure; non‑isolated VM/Docker setups can risk accidental destruction.

02. Rolling Release

A rolling release updates a subset of servers at a time: stop a server, deploy the new version, bring it back online, then move to the next server until the whole cluster is updated.

Rolling Release Characteristics

More resource‑efficient than blue‑green because only one set of instances is needed.

Rollback can be difficult.

Rolling Release Precautions

The environment may not be fully reproducible during the rollout.

Modifies the existing environment.

Rollback is painful, especially when many instances have already been updated.

Dynamic scaling during rollout can cause node‑version mismatches.

Temporary version inconsistencies may affect high‑availability requirements.

03. Canary (Gray) Release

Canary (or gray) release gradually shifts traffic from the old version to the new one, often using a small subset of servers with low weight and increasing it over time. It allows early detection of issues while keeping overall system stability.

In the 17th century, miners used canaries to detect toxic gases; the birds would die before humans were affected, prompting evacuation.

Prepare artifacts: build packages, test scripts, configuration files, deployment manifests.

Deploy a “canary” server and run tests.

Remove the canary from the load balancer.

Upgrade the canary application (drain traffic, deploy).

Run automated tests.

Re‑add the canary to the load balancer after health checks.

If tests pass, roll out to the remaining servers; otherwise roll back.

04. A/B Testing

A/B testing differs from deployment strategies: it runs multiple fully tested versions simultaneously to compare business metrics such as conversion rate or order volume. The goal is to evaluate the effectiveness of different implementations rather than to ensure release stability.