A deployment strategy is usually described by how it moves traffic, which is the least interesting thing about it. Blue green swaps all of it at once. Canary moves a little and then more. Rolling replaces instances a few at a time. Those are the mechanics, they are easy to explain, and they are not the reason one strategy is better than another on a given system.

What a strategy actually decides is two things: how much of your traffic is exposed to a bad version before you find out, and how long it takes to stop exposing it. Everything else is implementation. A canary that nobody watches is worse than an in place deployment, because it takes longer and gives you the same answer. A blue green swap with a tested, one command rollback is better than a slow canary with no rollback path, even though it exposes everything at once, because the window is short and the exit is certain.

The thing being bought is not uptime

It is tempting to say these strategies buy zero downtime, and for the simplest case that is true: you stop sending traffic to old instances only after new ones are accepting it, so no request lands on nothing. But zero downtime is achievable with a rolling restart behind a load balancer, which almost every orchestrator does by default, and nobody designs a release process around that alone.

What you are buying is bounded exposure. A deployment is an experiment whose hypothesis is that the new version works in production, and the strategies in this lesson differ in how cheaply they let you be wrong. Bounded exposure has a specific meaning: the number of users who see the broken behaviour is a function of how fast you detect it and how fast you reverse it, and a strategy that improves either of those numbers is doing its job.

This reframing matters because it tells you what to invest in. Teams spend weeks building a sophisticated traffic shifting mechanism and then detect failures from a customer email forty minutes later. The traffic mechanism was the cheap half.

Four shapes, and what distinguishes them

In place deployment stops the old version and starts the new one. Simple, brief unavailability, and rollback means another deployment, which takes as long as the first one did. It is the right choice more often than its reputation suggests, specifically for internal tools and for anything where a minute of unavailability costs nothing.

Rolling deployment replaces instances in batches. No unavailability, no second environment, and you have both versions serving simultaneously for the duration, which is a real constraint rather than an incidental detail. Rollback means rolling back through the batches, so the reverse takes about as long as the forward direction did.

Blue green runs two complete environments and switches between them. The switch is atomic from the traffic point of view, rollback is the same switch in reverse and takes seconds, and the cost is that you run two of everything for the duration, plus the much harder problem of what the two environments share.

Canary sends a small fraction of traffic to the new version, measures, and either increases the fraction or reverts. It is the only one of the four that produces evidence about production behaviour before full exposure, and it is also the only one whose correctness depends on you having instrumented the thing well enough to read that evidence.

Detection is the part people skip

Every one of these strategies has a step that reads "observe whether it is healthy", and that step is where almost all real deployment failures live. The traffic mechanics are deterministic and testable. The observation is a judgement made under time pressure with partial information, and most teams have not decided in advance what they are looking at.

Concretely, you need to know before you start: which metrics decide the outcome, what their normal range is for this time of day, how long you have to wait before the sample means anything, and who or what is allowed to call it off. If any of those four is undecided when the rollout begins, the strategy degrades into an in place deployment with extra steps, because the decision will be made by whoever notices something and the exposure window will be as long as it takes somebody to notice.

This is why automated analysis is worth more than a more elaborate traffic split. A canary that automatically aborts on an error rate above a threshold has a bounded exposure window even at three in the morning. A canary that requires a human to look at a dashboard has an exposure window equal to that human's response time, which at three in the morning is not a number you want in your reliability model.

The two numbers that define a strategy

If you want to compare strategies honestly, write down two numbers for each.

The first is exposure integral: the fraction of traffic on the new version, multiplied by the time it serves before you decide, summed over the rollout. An in place deployment has an exposure integral of one hundred percent multiplied by your detection time. A canary at five percent for ten minutes has an exposure integral twenty times smaller for the same detection time, which is the entire argument for canarying.

The second is reversal time: wall clock from the decision to revert to the moment no user is served by the bad version. Blue green wins this outright when the environments are genuinely independent, because it is a routing change. Rolling loses badly, because reverting means another rolling pass. Canary is fast for the canary fraction and no better than rolling for a rollout that has already completed.

These two numbers also explain the combinations people actually run. Canary to get a small exposure integral during the risky early phase, then blue green style promotion so that reversal stays fast after full traffic is on the new version. That combination is common not because it is fashionable but because the two numbers point in different directions and you want both.

Why in place deployment survives

It is worth defending the simple option, because teams adopt complex strategies for services that do not need them and then maintain that complexity forever.

In place deployment is correct when the cost of brief unavailability is lower than the cost of running and reasoning about a second environment. That covers internal admin tools, batch jobs between runs, development environments, and a surprising number of low traffic services whose users would not notice a thirty second gap. It is also the only option that keeps the mental model trivially simple, which matters when the person deploying at midnight is not the person who built the pipeline.

The failure mode to avoid is adopting a blue green or canary mechanism and then not maintaining the parts that make it work. A canary with a stale set of analysis metrics is not a canary. A blue green setup where the idle environment has drifted out of date is a trap: the day you switch to it, you discover it has an old configuration, and the rollback you were counting on makes things worse.

Health checks, and what they do not tell you

Every strategy here depends on a readiness signal, and it is worth being precise about what that signal covers, because it is routinely overestimated.

A liveness check answers whether the process should be restarted. A readiness check answers whether this instance should receive traffic. Neither answers whether the new version is correct. An instance that returns a two hundred on its readiness endpoint while silently writing malformed records to a queue is healthy by every definition your orchestrator uses, and the rollout will proceed happily to completion.

This gap is the reason canary analysis looks at business and application metrics rather than process health. The readiness check tells you the deployment mechanics worked. Only the metrics that describe what the service does for its users can tell you the deployment was a good idea.

Choosing the shape from the constraints

The decision falls out of three questions, asked in order.

Can you run two versions of this service simultaneously without breaking anything? If the answer is no, usually because of a schema change or a stateful protocol, then rolling and canary are off the table until you have made the change compatible, and you are choosing between in place and blue green.

Do you have metrics that would reveal this class of failure within a few minutes at a small traffic fraction? If not, canary buys you very little, and you should prefer whichever strategy has the fastest reversal, which is blue green.

Is the cost of a second environment acceptable? If not, rolling with a well tested revert path is the honest answer, and you accept the slower reversal.