Before fully switching resident traffic over to a new version of the 311 assistant, a city team routes a small percentage of live requests to the new version and compares its outcomes against the current production version before expanding further. What deployment strategy is this?
Select an answer to reveal the explanation.
Short Explanation
Think of it like taste-testing a new recipe on a few diners before it goes on the full menu. Only a small slice of resident traffic hits the new version first, while the team watches how it performs before expanding. That gradual, traffic-percentage-based exposure is what makes it a canary rollout rather than a full swap.
Full Explanation
A canary or staged rollout exposes a small, controlled percentage of live production traffic to a new version while the majority keeps hitting the proven version, letting the team compare real-world outcomes — accuracy, latency, error rate — before gradually increasing the new version's traffic share, which limits the blast radius of a bad release. Blue/green stands up a second full parallel environment and cuts traffic over wholesale once it's validated, rather than exposing a gradually increasing slice of live traffic during validation. Rollback is a recovery action taken after a bad release is already discovered, not a controlled way of introducing a new one. An in-place upgrade replaces the running version directly with no comparison window at all, the opposite of what's described here. Caveat: canary rollouts need a clear, pre-defined success threshold and comparison metric, or the small-percentage window can drag on without ever reaching a decision. Operational check: define the canary traffic percentage and the specific metrics — error rate, latency, accuracy — that must hold before promoting the new version to full traffic.