Mastering Blue‑Green, Canary, and Dark Launch Deployments: A Practical Guide

Blue‑Green Deployment

A deployment pattern that keeps two identical production environments running in parallel. The blue environment hosts the current stable version, while the green environment hosts the new version that is ready for release.

Key Concepts

Isolation: Both environments are provisioned with the same hardware, OS, runtime, and configuration to ensure that a switch does not introduce unexpected differences.

Traffic Switch: A router, load‑balancer, or DNS entry is used to redirect all incoming requests from blue to green once the new version is validated.

Rollback: If a problem is detected after the switch, traffic can be instantly reverted to the blue environment, providing near‑zero‑downtime rollback.

Typical Workflow

Provision a green environment that mirrors the blue production stack.

Deploy the new application version to green and run integration and smoke tests against real production data.

Optionally place the application in read‑only mode, run a short verification window, and then switch the load‑balancer to point to green.

Monitor key metrics (latency, error rate, business KPIs). If they stay within thresholds, keep green live.

If a failure occurs, revert the load‑balancer back to blue and investigate without affecting users.

After a successful release, repurpose the former blue environment as the next green candidate.

Database Migration Strategy

Because the two environments usually share the same database, schema changes must be backward compatible. A common practice is to apply database migrations in two phases:

Deploy a migration that adds new columns or tables while keeping the old schema functional.

Deploy the application code that uses the new schema.

After the new version is stable, clean up deprecated schema elements in a separate release.

Canary (Gray) Deployment

Also known as gray release, this approach routes a small, configurable percentage of user traffic to the new version while the majority continues to use the current version. The traffic share is increased gradually as confidence grows.

Process

Deploy the new version alongside the stable version.

Configure the router or service mesh to send an initial fraction (e.g., 5‑10%) of requests to the new version.

Collect operational metrics (error rate, latency, business conversion, resource usage).

If metrics remain within acceptable bounds, increase the traffic share (e.g., 25 %, 50 %, 75 %).

Continue until the new version handles 100 % of traffic, or roll back immediately if a regression is detected.

Metrics to Observe

Request latency and throughput.

Error and exception rates.

Business‑level KPIs (e.g., conversion rate, revenue per user).

System resource utilization (CPU, memory, I/O).

Dark Launch / Feature Toggle

A dark launch (feature toggle) deploys new functionality to production but keeps it hidden from end users until the toggle is turned on. This enables real‑world testing, data collection, and rapid rollback without redeploying code.

Implementation Pattern

if (FeatureToggle.isEnabled("newRecommendationAlgorithm")) {
    // Execute new algorithm
    recommendations = NewAlgorithm.generate(user);
} else {
    // Fallback to stable algorithm
    recommendations = OldAlgorithm.generate(user);
}

Operational Considerations

The toggle value should be stored in a globally accessible, low‑latency store (e.g., distributed config service, database, or cache).

Feature toggles act as a remote “kill switch”; turning the flag off instantly disables the new code path.

Toggle changes should be auditable and, if possible, version‑controlled to trace who changed the flag and when.

Avoid long‑lived toggles; remove the conditional code once the feature is proven stable.

References

https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

https://tech.youzan.com/gray-deloyments-and-blue-green-deployments-practices-in-youzan/

http://stormluke.me/deploy-not-equal-release-part-one/

https://martinfowler.com/bliki/BlueGreenDeployment.html