Blue‑Green, Rolling, and Canary Deployment Strategies Explained

During project iteration, releasing new versions inevitably involves deployment, which brings modification and risk; this article summarizes common deployment and release techniques.

For example, a Weibo project with a major new version must switch users from the old to the new system after testing.

Blue‑Green Deployment

Blue‑green deployment uses two complete environments: the currently serving (green) version and the new (blue) version. The blue environment is isolated for testing and, once validated, traffic is switched to it; both environments may coexist briefly to allow rollback if needed.

The blue system is used for pre‑release testing without affecting users; after thorough testing it becomes the production system, and the old green system can be decommissioned.

Characteristics of Blue‑Green Deployment

Reduces downtime and enables fast rollback.

Requires two completely independent environments to avoid interference.

Precautions

Blue‑green is not a universal solution; it assumes the target system is relatively self‑contained. Complex systems may need careful data synchronization, handling of in‑flight transactions, and sufficient infrastructure support. Deploying on non‑isolated platforms (VMs, Docker) can introduce risks.

Rolling Deployment

Rolling deployment updates a subset of servers at a time: stop a server, update it, bring it back online, then proceed to the next server until all instances run the new version.

Unlike blue‑green, rolling deployment can be performed with a single set of machines, replacing old instances with new ones sequentially.

Characteristics of Rolling Deployment

More resource‑efficient because it does not require duplicate clusters; only a fraction of instances are updated at a time.

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

Precautions

The environment after each step is not guaranteed to be fully stable, making it hard to verify the old version’s correctness.

Modifies the existing environment, which may affect ongoing traffic.

Rollback may be painful; for example, updating 100 instances in batches of 10 could require a lengthy rollback if an issue appears at the 80th instance.

Dynamic scaling during rollout can complicate which nodes run which code.

Version inconsistency during the rollout may affect scenarios with strict uptime requirements.

Canary (Gray) Deployment

Canary deployment, also called gray or “golden‑canary” release, gradually shifts traffic from the old version to the new one, often using A/B testing to expose a small user segment to the new version before wider rollout.

It ensures overall system stability by detecting and fixing issues early; the process can involve assigning low traffic weight to a few servers and increasing it step by step (traffic splitting).

In the 17th century, British miners used canaries to detect poisonous gases; the birds would stop singing or die before humans noticed the danger, prompting evacuation.

Process:

Prepare deployment artifacts for each stage (build, test scripts, config, manifests).

Deploy a “canary” server and run tests.

Remove the canary from the load‑balancer pool.

Upgrade the canary application (drain traffic and deploy).

Run automated tests on the upgraded canary.

Add the canary back to the load‑balancer after health checks.

If the canary passes, roll out the upgrade to the remaining servers; otherwise roll back.

A/B Testing

A/B testing is distinct from deployment strategies; while blue‑green, rolling, and canary aim to ensure stability of a new release, A/B testing evaluates the performance of multiple versions simultaneously (e.g., conversion rate, order volume) after they have already passed release criteria.

During an A/B test, different user groups experience different versions (e.g., UI style, workflow) and the results are analyzed to select the most effective version.

Source: cnblogs.com/Courage129/p/14498788.html

Backend‑Specific Technical Group

Build a high‑quality technical community; developers, recruiters, and job‑seekers are welcome to share opportunities and help each other grow.

Please communicate civilly, focusing on technical exchange , job referrals , and industry discussion .

Advertisements and private solicitations are prohibited; beware of scams.

Contact the author to join the group.