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

During project iteration, releasing new versions inevitably involves deployment, which carries risk; therefore, many deployment techniques have been developed to mitigate these risks.

For example, if you are responsible for a large‑scale project like Weibo and a new version introduces significant changes to architecture and UI, you need a reliable way to switch users to the new version after testing.

01. Blue‑Green Deployment

Blue‑green deployment maintains two complete environments: the currently serving (green) version and the new (blue) version. The blue environment is used for pre‑release testing without affecting users. Once it passes all checks, traffic is switched to blue, which then becomes the new green environment; the old green can be decommissioned.

02. Characteristics of Blue‑Green Deployment

Reduces downtime during release and enables rapid rollback.

Requires two fully isolated environments to guarantee no interference.

03. Considerations for Blue‑Green Deployment

It is not a universal solution; complex systems may need careful data synchronization.

Unfinished or new business logic must be handled when switching.

Database compatibility and rollback strategies must be planned.

Infrastructure support is required; non‑isolated setups (VM, Docker) increase risk of environment destruction.

04. Rolling Deployment

Rolling deployment 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 all instances run the new code.

05. Characteristics of Rolling Deployment

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

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

06. Rolling Deployment Considerations

There is no guaranteed fallback environment; you cannot easily revert to a known good state.

Partial updates may cause temporary incompatibilities between old and new versions.

Dynamic scaling during rollout adds complexity in tracking which nodes run which code.

Short periods of version mismatch require careful compatibility handling.

07. Canary (Gray) Deployment

Canary (gray) deployment gradually shifts traffic to a small set of servers (the "canary") and monitors performance; if stable, the rollout expands. This approach allows early detection of issues and smooth traffic shifting, often using traffic‑splitting techniques.

08. A/B Testing

A/B testing differs from deployment strategies: it runs multiple fully tested versions simultaneously to compare user‑facing metrics such as conversion rates. While deployment methods ensure stability, A/B testing evaluates the effectiveness of different implementations.