Blue‑Green, Rolling, and Canary Deployment Strategies Explained

During a project’s iteration, releasing a new version inevitably involves deployment, which brings modification and risk; the article summarizes common deployment techniques.

Blue‑Green Deployment

Blue‑green deployment uses two identical environments: the current live system (green) and a new version (blue). The blue environment is used for pre‑release testing without affecting users. Once validated, traffic is switched to blue, which then becomes the new green after the old green is retired.

Characteristics

Reduces downtime and enables quick rollback.

Requires two fully independent systems to avoid interference.

Considerations

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

Database synchronization and handling in‑flight transactions can be complex.

Needs supporting infrastructure; on non‑isolated platforms (VM, Docker) there is risk of destroying environments.

Rolling Deployment

Rolling updates replace instances one (or a few) at a time: stop a server, update it, then bring it back online, repeating until all nodes run the new version.

Characteristics

More resource‑efficient than blue‑green because only one cluster is needed.

Rollback can be difficult, especially when many instances have already been updated.

Considerations

During the rollout the environment is partially mixed, making it hard to guarantee stability.

Unfinished or new requests must be handled carefully; database compatibility is critical.

Dynamic scaling during rollout adds complexity in tracking which node runs which version.

Temporary version mismatches may affect services that require strict consistency.

Canary (Gray) Deployment

Canary deployment (also called gray release) gradually shifts traffic from the old version to a new one, often starting with a small subset of servers or users (e.g., 10 servers with low weight) and increasing the weight as confidence grows.

The process typically includes preparing artifacts, deploying a canary server, testing, removing it from the load balancer, upgrading, automated testing, re‑adding it, and then rolling out to the remaining servers if successful.

A/B Testing

A/B testing differs from deployment strategies: it runs multiple fully‑tested versions simultaneously to compare business metrics such as conversion rates, rather than focusing on stability or bug detection.

While blue‑green, rolling, and canary aim to ensure a stable release, A/B testing evaluates the effectiveness of different implementations.

Source: Java 旭阳