Blue/Green Deployment, Rolling Update, and Canary Release: A Comparative Overview

During project iteration, deployment is inevitable; deployment involves modifications that introduce risk. Various deployment techniques exist, ranging from simple to complex, some requiring downtime while others do not. This article summarizes common deployment strategies.

1. Blue/Green Deployment

Definition

Blue/Green deployment runs the old version continuously while a new version is deployed and tested; once verified, traffic is switched to the new version, and the old version can be upgraded.

Characteristics

It requires no downtime and carries low risk.

Deployment Process

Step 1: Deploy version 1 (initial state)

All external traffic is directed to version 1.

Step 2: Deploy version 2

Version 2 contains new code (features, bug fixes, etc.).

Step 3: Switch traffic from version 1 to version 2

Step 4: If version 2 passes testing, delete resources of version 1 and officially use version 2

Summary

The application remains online throughout the process; the old version is untouched during the new version rollout, allowing easy rollback at any time as long as the old resources are retained.

Precautions

When switching to the blue environment, handle unfinished and new business properly; ensure the database backend can cope; coordinate micro‑service and monolithic applications; plan database‑application synchronization and rollback; have infrastructure support; avoid risks on non‑isolated platforms (VM, Docker, etc.).

2. Rolling Update

Definition

Rolling update updates a subset of servers at a time: stop service on selected instances, apply the update, then bring them back online, repeating until the entire cluster runs the new version.

Characteristics

It saves resources compared to Blue/Green because only one cluster is needed, and only a fraction (e.g., 20%) of instances may be updated at once.

Drawbacks include:

(1) No guaranteed “good” environment during rollout.

(2) Modifies the existing environment.

(3) Rollback is difficult and time‑consuming.

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

(5) Temporary version mismatches may affect high‑availability requirements.

3. Gray Release / Canary Deployment

Definition

Gray release (or canary deployment) gradually shifts traffic from an old version to a new one, often using A/B testing: a subset of users sees version B while the rest stay on version A; if B performs well, the rollout expands.

Note: The term “canary” comes from 17th‑century coal mines where canaries warned miners of dangerous gas levels.

Structure diagram:

Steps

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

Remove the “canary” server from the load‑balancer pool.

Upgrade the “canary” application (drain traffic, deploy).

Run automated tests on the upgraded canary.

Add the canary back to the load‑balancer (health checks).

If tests succeed, upgrade the remaining servers; otherwise roll back.

Additional capabilities include adjusting routing weights to validate new versus old versions.

Reference

https://www.v2ex.com/t/344341