Deployment Strategy English: Blue-Green, Canary, and Feature Flags

Introduction

Modern software teams ship code continuously, and they have developed a rich vocabulary for the strategies and techniques that make continuous delivery safe. Whether you are discussing a release plan in a sprint review, explaining a production issue to a non-technical stakeholder, or writing a deployment runbook, understanding the terms in this post will help you communicate deployment strategy with precision and confidence.

Deployment Strategy Vocabulary

Blue-green deployment — A release strategy that maintains two identical production environments, called blue and green. At any given time, one environment is live and serving traffic while the other is idle. When a new version is ready, it is deployed to the idle environment, tested, and then traffic is switched over instantaneously, making the idle environment the new live one.

“We use blue-green deployment for our main API service — the switch is near-instantaneous for users, and if something goes wrong we can revert traffic to the previous environment in under a minute.”

Canary release — A deployment technique where a new version of a service is released to a small percentage of users before being rolled out to the full user base. The term comes from the historical use of canaries in coal mines as early warning systems.

“We did a canary release of the new checkout flow to 5 percent of users on Friday evening — the error rate stayed flat for 24 hours, so we expanded to 25 percent on Saturday and went full rollout on Monday.”

Feature flag — A software mechanism that allows engineers to enable or disable a feature at runtime without deploying new code. Feature flags decouple deployment from release, allowing code to be shipped to production in a dormant state and activated when the team is ready.

“The new recommendation engine has been in production behind a feature flag for two weeks — we are planning to enable it for all users next Tuesday after the final A/B test results come in.”

Rollback — The process of reverting a deployment to a previous known-good version of the software, typically in response to a production incident, unexpected errors, or a failed health check after a release.

“Within three minutes of the deployment, our error rate spiked above the SLO threshold — we triggered a rollback immediately and were back to the previous version within five minutes.”

Promote to production — To advance a build or artifact through the deployment pipeline stages from a lower environment, such as staging or pre-production, into the live production environment. Promotion typically follows a set of validation gates.

“Once the QA team signs off on the staging environment and all integration tests pass, the release manager will promote to production during the Thursday maintenance window.”

Dark launch — A technique where a new feature or code path is executed in production for real users but its output is hidden or discarded rather than shown to the user. It allows engineers to test new code under real production load without affecting the user experience.

“We dark-launched the new search indexing algorithm for a week — we sent the results to a shadow log rather than to the user interface, which let us validate performance and correctness without any user-facing risk.”

Traffic splitting — The practice of dividing incoming requests between two or more versions of a service, typically using a load balancer or API gateway rule. Traffic splitting is the core mechanism behind canary releases and A/B testing in production.

“We configured traffic splitting at the nginx layer — 90 percent of requests go to the stable version, and 10 percent are routed to the experimental endpoint so we can compare response times under real load.”

Gradual rollout — A controlled deployment approach where a new version is released to progressively larger segments of users or infrastructure over time, with validation checks at each stage before expanding further.

“The gradual rollout went smoothly: 1 percent on Monday, 10 percent by Wednesday, 50 percent by Friday, and full rollout the following Monday after five days of clean metrics.”

Choosing the Right Strategy

Each deployment strategy has a different risk and complexity profile. Blue-green deployment is excellent for near-zero-downtime releases but requires maintaining double the infrastructure. Canary releases are well-suited for user-facing changes where you want to observe real behavior at small scale before full exposure. Feature flags offer the most flexibility but introduce ongoing maintenance overhead — flags that are never cleaned up become technical debt.

Dark launches are underused but extremely powerful for validating backend changes under production load without any user impact. Gradual rollouts with automated rollback triggers represent the current best practice for most high-traffic production systems.

Communicating Deployment Plans

When writing or presenting a deployment plan, be specific about the strategy you are using and why. Do not just say “we will deploy on Thursday.” Say “we will do a canary release at 5 percent on Thursday, monitor error rates and latency for 24 hours, and expand to full traffic on Friday if metrics stay within SLO thresholds — otherwise we will roll back.” That level of specificity demonstrates engineering maturity and builds confidence with stakeholders who need to understand the risk profile of each release.