Mastering Deployment Strategies: Blue‑Green, Rolling, Canary & A/B Testing

During project iteration, deployment (or redeployment) is inevitable, and each modification introduces risk. This article summarizes common deployment and release techniques.

For example, if you are responsible for a major version upgrade of a Weibo project that changes service architecture and front‑end UI, and testing shows no functional issues, how do you switch users to the new version?

Blue‑Green Deployment

Blue‑green deployment uses two complete environments: the current production system (green) and the new version (blue). Both are fully functional; only the version and external exposure differ.

The blue environment is not exposed to users; it is used for final testing and any necessary fixes without affecting the live system.

After thorough testing and verification, traffic is switched to the blue environment. Both environments may coexist briefly to monitor the new system; if problems arise, traffic can be switched back to green.

When the blue environment is confirmed stable and the green environment is no longer needed, the blue system becomes the new production (green) system, and the old green resources can be reclaimed.

Blue‑Green Features

Reduces downtime during release and enables fast rollback.

Guarantees zero interference only when the two environments are completely decoupled.

Blue‑Green Considerations

Blue‑green is one release strategy and is not a universal solution. It works best for tightly‑coupled systems; complex systems may require careful handling of data synchronization and cut‑over procedures.

When switching to the blue environment, unfinished or new business must be handled properly; database compatibility can become a challenge.

Coordinating micro‑service and monolithic applications may cause service interruptions if not managed well.

Database migration and rollback need prior planning.

Infrastructure support is required.

On non‑isolated infrastructures (VM, Docker, etc.) the blue and green environments may be at risk of destruction.

Rolling Deployment

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

Unlike blue‑green, rolling deployment can be performed with a single machine (or a small set). The new version is deployed to a server, which then replaces the currently running server; the process continues until all servers are updated.

Rolling Features

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

Rollback can be difficult.

Rolling Considerations

There is no guaranteed fallback environment; unlike blue‑green, the previous version may not be readily available.

The existing environment is modified during the rollout.

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

Dynamic scaling during rollout can cause uncertainty about which nodes run which code.

Transient mismatches between old and new versions may affect high‑availability requirements.

Canary (Gray) Deployment

Canary deployment, also known as gray release, gradually shifts traffic from the old version to a new one. A/B testing is a form of canary where a subset of users sees version B; if no issues are observed, the rollout expands.

On the server side, traffic can be split by assigning lower weight to a small group of servers initially, then increasing the weight as confidence grows.

In the 17th century, British coal miners used canaries to detect dangerous gas levels; the birds would stop singing or die before humans noticed the hazard.

Process:

Prepare artifacts for each stage: build packages, test scripts, configuration files, and deployment manifests.

Deploy a “canary” server and run tests.

Remove the canary server from the load‑balancer pool.

Upgrade the canary application (drain traffic, deploy new version).

Run automated tests on the upgraded canary.

Add the canary server back to the load‑balancer (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 blue‑green, rolling, and canary releases. The latter are release strategies aimed at ensuring stability of a new system.

A/B testing evaluates the actual effect of different service versions (e.g., conversion rate, orders) by running multiple versions simultaneously, often after they have been deployed via a strategy such as blue‑green.

During an A/B test, variations may include UI changes, colors, or workflow differences; analysts compare performance metrics to select the best‑performing version.