Overview of Blue‑Green, Rolling, Canary, and A/B Testing Deployment Strategies

Blue‑Green Deployment

Blue‑green deployment maintains two identical production environments: the current "green" (old) version serving traffic and a separate "blue" (new) version used for testing and validation. Once the blue environment passes all checks, traffic is switched to it, allowing a quick rollback to green if problems arise. The approach minimizes downtime and enables rapid rollback, but it requires sufficient resources to run two full environments and works best for tightly‑coupled services.

Key Characteristics

Reduces interruption time during release and enables fast rollback.

Both environments must be decoupled to avoid interference.

Considerations

Not a universal solution; complex systems may need careful data synchronization.

Database compatibility and transaction handling must be planned.

Infrastructure support is required, and non‑isolated platforms (VM, Docker) can increase risk of accidental destruction.

Rolling Deployment

Rolling deployment updates a subset of servers at a time, replacing old instances with new ones sequentially until the entire cluster runs the new version. Only a single set of machines is needed, and each update cycle involves deploying to one server, swapping it into service, then moving to the next.

Key Characteristics

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

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

Considerations

No single “known‑good” environment during the rollout, making issue detection harder.

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

Dynamic scaling and load‑balancing must be carefully managed to avoid traffic loss.

Canary (Gray) Deployment

Canary deployment (also called gray or A/B testing) gradually shifts a small portion of traffic to a new version, monitors its behavior, and expands the rollout if no issues are observed. It often involves assigning lower weight to a few servers and increasing it over time, effectively performing a controlled traffic split.

Process

Prepare build artifacts, test scripts, configuration, and deployment manifests.

Deploy the canary instance and run tests.

Remove the canary from the load‑balancer, upgrade it, and re‑add it after health checks.

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

A/B Testing

A/B testing differs from release strategies; it evaluates the performance of multiple already‑deployed versions (e.g., conversion rate, order volume) by exposing different user groups to each variant. The goal is to determine which version delivers better business outcomes, not to ensure stability of a new release.

Final Note

The author includes links to PDF collections of Spring Cloud, Spring Boot, and MyBatis advanced topics, encouraging readers to follow the public account for more resources and to like, share, and comment on the article.