Simulating CI/CD Deployment Strategies: Blue-Green, Canary, and Rolling Rollouts

A pipeline is a state machine, not just a checklist

It is tempting to describe a continuous integration and continuous delivery (CI/CD) pipeline as a simple checklist: commit code, build it, test it, ship it. In practice a pipeline is better modelled as a state machine moving a single artifact through a sequence of environments, each with its own pass/fail gate. A commit enters the system as a candidate; it becomes a build artifact once compiled; that artifact becomes a release candidate once it clears automated tests; and it becomes a production deployment only after passing whatever rollout policy the team has chosen. Every arrow between those states can fail, and every failure either bounces the artifact back to the developer or halts it in place pending a rollback.

Treating the pipeline this way is useful because it makes the interesting engineering question explicit: not "does the code work" but "how much of our live traffic is exposed to a given version of the code at any given moment, and how quickly can we change that exposure if something goes wrong." That question is what deployment strategies actually answer, and it is what makes deployment strategy a genuinely simulate-able system — you can model traffic share as a function of time and watch different strategies produce very different risk curves for the same underlying bug.

Blue-green: an instantaneous switch between two complete environments

In a blue-green deployment, two full copies of the production environment exist simultaneously — call them "blue" (currently live) and "green" (the new version). The new release is deployed entirely to green while blue continues serving 100% of traffic, so users see nothing during the deployment itself. Once green passes smoke tests, a router or load balancer flips all traffic to green in a single step, typically by updating a DNS record, load balancer target group, or service mesh routing rule.

The defining property of blue-green is that traffic exposure to the new version is a step function: 0% until the cutover instant, then 100% immediately after. This makes rollback trivial — flip the router back to blue — which is why blue-green is popular for changes that are hard to partially roll back, such as database schema migrations paired with application code changes. The cost is resource duplication: you need enough spare capacity to run two full production environments at once, even if only briefly, and any bug that only manifests under real production load and traffic mix will affect every user simultaneously the moment the switch happens, since there is no intermediate exposure level to catch it earlier.

Canary: a slowly widening exposure curve

A canary deployment routes a small, deliberately chosen slice of live traffic to the new version — often starting at 1% to 5% — while the rest continues to hit the known-good version. If error rates, latency, and business metrics for the canary slice stay within acceptable bounds for an observation window, the traffic share is increased in steps (5% → 25% → 50% → 100%), with the same health checks re-evaluated at each step. If metrics degrade at any point, the canary is rolled back by simply routing traffic away from it, and only a small fraction of users were ever affected.

The name comes from the historical practice of miners carrying canaries into coal mines as an early warning system for toxic gas — the canary would show distress before the gas reached lethal concentration for humans. In software, the "canary" traffic slice plays the same role: it surfaces a regression while the blast radius is still small. The exposure curve for a canary deployment is a staircase that rises over minutes to hours rather than a single step, and the key design parameters are how large each step is, how long the observation window is at each step, and which metrics trigger an automatic rollback versus require a human decision.

Canary deployments require infrastructure that can split traffic at a fine grain — typically a service mesh (such as Istio or Linkerd) or an application-aware load balancer — and they require automated, statistically meaningful health checks, because comparing error rates from a 2% traffic sample against a 98% baseline sample is a real statistical inference problem, not just a raw count comparison. Too small a canary slice, or too short an observation window, and genuine regressions can slip through as noise.

Rolling deployment: replacing instances gradually

A rolling deployment updates a fleet of running instances (servers, containers, or Kubernetes pods) a few at a time rather than all at once. A typical policy might take down 25% of instances, replace them with the new version, wait for them to pass health checks and rejoin the load-balanced pool, then repeat with the next 25%, until the whole fleet is running the new version. Unlike blue-green, there is no separate duplicate environment — the fleet gradually transforms in place — and unlike canary, the traffic split is a side effect of how many old versus new instances are currently registered with the load balancer, not a deliberately controlled percentage.

This makes rolling deployments resource-efficient (no need to double capacity) but slower to roll back cleanly, since reverting means running the same gradual replacement process in the opposite direction. It also means that for a period of minutes, both old and new versions are genuinely live at once and must be compatible with the same clients, the same database schema, and each other — a constraint sometimes called "N-1 compatibility," since any given moment might have version N and version N-1 both serving requests against the same database.

Modelling risk as a function of blast radius and detection time

The reason these three strategies are worth comparing side by side is that they trade off two independent variables: how large a fraction of users are exposed to a bug before it's caught (blast radius), and how long it takes to detect and reverse that exposure once the bug starts causing damage (mean time to detect plus mean time to rollback). Blue-green minimizes deployment duration and complexity but maximizes blast radius, since a bug is instantly live for everyone. Canary minimizes blast radius at the cost of a longer, more operationally complex rollout with staged health checks. Rolling deployment sits in between: blast radius grows in discrete chunks equal to the batch size, and detection depends on whether health checks are actually sensitive to the specific failure mode.

A useful way to reason about this quantitatively is to imagine plotting "fraction of users on the new version" against time for each strategy, and overlaying "cumulative user-impact of a hypothetical regression" as the area under that curve up until the moment automated or human intervention reverses the rollout. Blue-green produces a curve that is either zero or maximal impact with almost no in-between; canary produces a curve whose slope you control directly through the size and timing of each traffic step; rolling produces a curve whose slope is set by batch size and instance replacement speed. None of these strategies is universally best — the right choice depends on how expensive a partial rollback is for that particular change (e.g., stateful vs. stateless, schema-coupled vs. independent) and how sensitive the available health signals are to the kind of regression the team is worried about.

Feature flags as an orthogonal, finer-grained control

Feature flags (also called feature toggles) decouple code deployment from feature exposure entirely. Code for a new feature can be deployed to 100% of instances — via any of the strategies above — while remaining dark (inactive) behind a flag that is off by default. The feature is then turned on gradually for specific user segments (a percentage of accounts, a specific customer, an internal team) independent of which server instance happens to handle a given request. This is a different axis from deployment strategy: deployment strategy controls which code is running where, while feature flags control which code path executes for a given user once it is running. Combining the two — for example, a rolling deployment that ships flagged-off code, followed by a flag-based canary that ramps up feature exposure by user segment rather than by instance — gives teams independent control over infrastructure risk and product risk, which is why most mature CI/CD setups use flags and rollout strategy together rather than relying on either alone.