Blue green and canary releases chosen by the risk of the change

The deployment strategy conversation is usually had as a preference between two tribes, blue green as the operational conservative's switch and canary as the statistician's slow ramp, and the truth is that the two strategies answer different questions about different kinds of change. The blue green deployment answers how do we make the switch instant and the rollback a single action, and it pays for that with double capacity and a migration constraint. The canary release answers how do we find out whether the new version is broken before everyone meets it, and it pays with the traffic shifting machinery and the time each release takes. This article builds both honestly, the mechanics of each, the database constraint that decides more than any preference, the metric gates that make a canary real rather than a slow rollout, and the decision rubric that assigns each change to the strategy its risk profile actually wants.

Blue green mechanics and the instant switch

The blue green deployment runs two identical environments, blue serving production traffic and green idle, and the release flow is green receives the new version, green warms, the smoke tests pass, and the router flips, every user on green in one action:

# the router state, one line, the whole strategy
upstream production { server green:8080; }
# rollback: server blue:8080;

The strategy's properties are its selling point and its cost in one list. The cutover is atomic, there is no mixed traffic, no version skew during the release window, and the applications that need every request on one version, the stateful caches, the protocol changes, find the property decisive. The rollback is the same single action in reverse, the blue environment still running the old version, warm and ready, and the rollback that takes a configuration change is the rollback that actually happens at three in the morning. The costs are equally concrete, the double capacity bill, the environment that idles at full size, the warm up period that keeps the fleet at twice the price for a slice of every day, and the data layer constraint that the next section treats at length, because the instant switch only switches the stateless tier honestly.

The blue green's operational requirements are the load balancer or the service mesh that can flip atomically, the environment parity that the infrastructure as code makes credible, and the smoke suite that validates green before the flip, because the green environment that was never tested is the gamble the strategy exists to avoid. The modern variants trim the cost, the blue environment sized to the minimum viable, the single region deployments that borrow the staging hardware, and the economics stay honest, the strategy prices at roughly one and a half times the single environment over time.

Canary mechanics and the gradual question

The canary release routes a small slice of production traffic to the new version and watches what happens:

# the traffic split, 5 percent to the canary
canary_weight = 5
stable_weight = 95

The ramp is the strategy's dial, five percent, twenty five, fifty, full, with the pause between steps, the observation window where the canary's metrics speak, and the gate that decides whether the ramp continues. The canary's property is the blast radius, the five percent that meets the broken version while the ninety five percent keep the old, and the defect that blue green would have delivered to everyone is delivered to a twentieth, and the rollback is the weight returning to zero, the canary drained while the stable version keeps serving.

The canary's requirements are the machinery the blue green does not need, the traffic splitting that the router or the mesh provides, the metric comparison that the observability stack feeds, and the decision logic, the progressive delivery controller, Argo Rollouts or Flagger, that automates the ramp, the gates and the abort. The canary without the gates is the slow rollout that delivers the broken version to everyone slightly later, and the gates are where the strategy earns its keep, the metric baseline from the stable version, the canary's metrics compared per step, the error rate and the latency and the business counters, and the automated abort when the comparison fails.

The database migration, the constraint that overrides preference

The deployment strategy's deepest constraint is the data layer, and the article's honest core is that the schema migration pattern from earlier in this series, expand and contract, is the precondition for either strategy. The blue green flip with a breaking migration is the split brain of schemas, the green version's first request writing the column the blue version cannot read, and the rollback to blue after the data changed is the rollback that corrupts rather than restores. The canary with a breaking migration is the same failure in slow motion, the five percent writing the new shape while the ninety five percent read the old, and the mixed traffic window is the schema incompatibility window.

The compatible migration, the expand phase, the new column nullable, the dual write, the backfill, is the version that both strategies deploy safely, because the new and old versions read and write the same wire-compatible schema, the canary's mixed traffic and the blue green's instant flip both operate on a database that speaks both versions' language. The contract phase, the drop and the rename, arrives in a later release, after the strategy's window closed, and the discipline that falls out is the release engineering rule that decides more deployments than any preference, the deployment that carries a breaking schema change carries no strategy at all, it carries a scheduled outage, and the strategies in this article apply to the releases that obey the expand and contract discipline.

The metric gates that make a canary a canary

The canary's gates deserve their own section because they are the difference between the strategy and the guesswork, and the gates that work are the service level indicators from the monitoring discipline, compared per step. The error rate is the first gate, the canary's error fraction against the stable's, and the threshold is the error budget language, the canary that burns the budget faster than the stable fails the gate. The latency is the second, the p99 compared, because the canary that succeeds slowly is the canary that fails the objective. The business counters are the third and the highest value, the orders per minute, the conversion rate, the checkout completions, because the metric that catches the broken business logic is the business metric that no infrastructure gate sees:

gate: error_rate   canary < stable * 1.5
gate: p99_latency  canary < objective
gate: orders_per_minute  canary within 10% of stable

The observation window is the gate's statistics, the five percent step that runs long enough for the traffic to speak, and the step duration that respects the metrics' aggregation windows, the minute level counters that need their minutes. The automated abort completes the machinery, the gate failure that drains the canary without the human's intervention, and the analysis report that the controller produces, the per metric comparison with the timestamps, is the release's evidence that the five percent deployment was a test and the test passed.

The progressive delivery controller in practice

The canary's machinery in the Kubernetes cluster has a canonical shape, and the Argo Rollouts specification reads as the strategy's whole logic in one document, the steps, the weights and the gates:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 10m }     # the observation window
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 50
        - pause: { duration: 10m }
      canaryService: orders-canary
      stableService: orders-stable

The controller creates the canary pods, shifts the weight through the service mesh's traffic split, waits the observation window, and consults the analysis template, the metric queries against the same Prometheus the service level discipline runs, and the analysis run that fails aborts the rollout, the canary scaled to zero, the stable untouched. The Flagger equivalent is the same logic in the other dialect, and the choice between them prices like every tooling choice in this series, the team's platform and the preference of the operators who will own the machinery, and both ship the feature that makes the canary real, the automated abort with the evidence attached.

One canary that failed, the story the gates write

The abort story is the practice's acceptance test, and the one worth telling is the checkout release that failed its twenty five percent step. The canary's five percent window passed, the error rate flat, the latency inside the objective, and the ramp continued to twenty five, where the business gate spoke, the orders_per_minute comparison, the canary's conversion rate thirteen percent below the stable's, a defect that no infrastructure metric would have named, the pricing rounding error that charged one cent more on the annual tier and the payment provider's decline rate spiking quietly in response. The controller's analysis run failed the gate at the step's end, the abort drained the canary, the stable version kept serving, and the total user impact was the twenty five percent traffic that met the defect for ten minutes.

The release postmortem wrote itself from the controller's evidence, the analysis run's metrics with the comparison, the abort's timestamps, the diff of the pricing change, and the fix shipped the next day and canaried through the same gates, passing at every step. The same defect under the flip strategy, the blue green's atomic cutover, would have reached one hundred percent of the traffic with the same decline spike, and the incident's duration would have been the rollback's detection time rather than the gate's ten minutes, and the comparison is the decision rubric's data point, the change with the testable business risk belongs on the canary, because the canary is the strategy that runs the test.

The decision rubric, per change rather than per team

The strategies compose rather than compete, and the decision rubric assigns each change to the strategy its risk profile wants. The stateless change with the schema compatible, the new endpoint, the feature flag flip, the dependency bump, deploys on the canary, the blast radius of a twentieth and the gates that catch the surprise. The change that needs version purity, the session format, the protocol bump, the stateful migration in its compatible phase, deploys on the blue green, the atomic cutover that the mixed traffic cannot tolerate. The change that is itself a rollback, the hotfix to the hotfix, deploys on whichever strategy is fastest, which is the blue green's flip in the environments that have it and the full rollout where they do not.

The rubric's working rules compress the whole practice, and the list is short:

1. Deploy schema changes through expand and contract, and no strategy until the schema is compatible;
2. Canary the stateless majority, with the gates that compare the canary against the stable per step;
3. Blue green the version purity changes, and accept the capacity price as the purity's premium;
4. Automate the gates and the abort, the canary without the abort is the slow rollout;
5. Keep the rollback rehearsed, the blue environment warm, the canary drain tested, and the runbook current;
6. Report the canary's evidence with the release, the metrics comparison is the release's proof, not ceremony.

The deployment strategy is the risk management applied to the act of shipping, and the team that matches the strategy to the change's actual risk profile, the canary for the testable majority, the blue green for the purity cases, the compatible schema as the precondition for both, ships its releases with the blast radius and the rollback that each change deserves. The preference argument dissolves at that point, because the strategies are not identities, they are tools, and the release process that uses both, deliberately, per change, is the process that has already answered the only question that matters, what happens when this one is broken.