Choose a deployment strategy by how versions can coexist, how traffic can be controlled, what evidence can reveal a regression, and how you would recover. Rolling replacement changes instances gradually. Blue-green deployment prepares another environment before switching traffic. A canary exposes a selected population to a candidate and uses observations to decide whether to expand it.
None of these names guarantees a safe release. An application can pass a readiness check and return incorrect results. Switching traffic back can restore an old binary while leaving new database writes behind. The strategy must fit those effects.
This comparison uses a hypothetical report API. It is a design exercise, not a production deployment benchmark.
Separate replacement from evaluation
Argo Rollouts documents rolling, blue-green and canary concepts, while noting that implementations differ across tooling. A useful review separates two questions: how does the candidate receive traffic, and what result permits the next step?
| Approach | Change being controlled | Evidence the team still needs |
|---|---|---|
| Rolling | Instances are replaced in bounded steps | New instances serve correct responses while old and new versions coexist |
| Blue-green | Traffic moves between prepared environments | Candidate environment works with real dependencies; traffic can return safely |
| Canary | A selected traffic population reaches the candidate | Candidate/control observations are comparable and sufficient for a decision |
These are starting points for a review, not mutually exclusive product categories. A team can prepare a second environment and gradually direct traffic to it. What matters is the actual routing, capacity and decision behavior.
Rolling replacement suits compatible versions
Suppose our report API changes an internal serialization implementation while preserving its public and database contracts. Gradual instance replacement can be a reasonable starting point because old and new instances can serve requests concurrently.
In a Kubernetes Deployment, maxSurge and maxUnavailable govern aspects of replacement capacity. They do not define whether a report is correct. Kubernetes also documents that a failed progress deadline produces a status condition rather than automatically rolling the Deployment back. See the Deployment documentation.
For this example, the release plan should identify the expected artifact, checks for report content and a way to compare failures by version. If replacement stalls, an operator or controller needs an explicit policy for deciding what happens next.
Do not equate a fraction of instances with the same fraction of requests. Load distribution, persistent connections and uneven workloads can change exposure. Inspect the routing system's actual behavior when a traffic percentage matters.
Blue-green moves the cutover boundary
Now imagine the report API needs a substantially different runtime configuration. Preparing a separate environment allows configuration and dependency checks before live traffic moves. The AWS deployment overview describes this separation and retaining the prior environment for recovery.
Write down what the two environments share. A shared database, object store or message queue can carry effects across the cutover. If the candidate writes data the old version cannot read, keeping the old environment alive does not make the rollback safe.
The transition also needs to account for work already in progress. Existing connections and background jobs may outlive a router change. Verify how the platform drains them, what deadline applies and which version handles a retried request.
Extra capacity is a practical constraint, but “twice the cost” is not a universal result. The duplicate portion may be only the application tier, and the overlap duration matters. Estimate the resources actually duplicated and label that estimate as a scenario until measured.
A canary needs a decision-quality signal
Suppose the report API changes a calculation used by a subset of customers. A candidate serving a limited population can help the team observe real behavior before broader exposure, provided that the population exercises the changed path and that its results can be assessed.
Google's canarying chapter discusses representative populations, attribution and shared failure domains. A service-wide average can hide a candidate regression; candidate and control need distinguishable measurements.
For our example, an evaluation record might include report correctness checks on authorized synthetic requests, request failures by version, latency for the affected report type and evidence that enough relevant work occurred. A clean interval with no requests to the changed path is inconclusive.
Define three possible outcomes before starting: promote, reject, or remain inconclusive. Missing telemetry should not silently select promote. Likewise, a dependency incident affecting both populations may require investigation rather than a confident claim that the candidate caused the failure.
Avoid presenting an arbitrary sample size or duration as universally sufficient. A rare end-of-month report may not be exercised by a short weekday canary. The traffic distribution and failure being investigated determine what observation would be useful.
Review recovery around state, not just traffic
For each strategy, walk through a concrete failure: the candidate returns invalid report totals after accepting new input. Identify which requests were affected, whether stored results need repair, and whether the previous version can operate on current data.
Retain the previously evaluated artifact and its required configuration. Rebuilding an old commit can introduce different dependencies; our guide to reproducible container builds explains why artifact identity matters. A rollback procedure also needs the compatible data state described in the review-and-rollback workflow.
Before choosing more sophisticated tooling, complete one release worksheet: compatibility assumptions, traffic boundary, observation, decision owner, stopping rule and recovery action. If you cannot fill in a useful observation, a canary controller will not invent one. If the old version cannot recover from the new state, a fast routing switch will not solve that incompatibility.
Research note: primary documentation reviewed October 28, 2026. The report API, worksheet and comparisons are illustrative design analysis. No live rollout, zero-downtime guarantee, traffic-routing measurement or cost comparison was executed.
