Progressive delivery

A basic canary can approximate exposure by changing the ratio of old and new replicas. With a small fleet, integer replica counts limit that approximation, and persistent connections can skew actual request shares. Argo Rollouts supports explicit canary steps and traffic-routing integrations for finer control. When routing and replica scaling are decoupled, ensure that the chosen number of canary replicas can handle the assigned traffic. A traffic weight is not a resource reservation.

Keep rollback capacity available when the recovery objective requires an immediate traffic shift. Running both versions may cost more temporarily, but terminating the old fleet too early can turn an abort into a slow scale-up. Determine whether the new version changes shared data, emitted events, or configuration in ways that the old version cannot understand. Traffic can be redirected quickly while an incompatible database mutation remains irreversible.

Choose metrics from user-visible behavior: successful completion, latency, correctness, and resource cost can all matter. Compare compatible traffic cohorts over the same interval. Sending only employees to the canary can be useful for early smoke testing but may miss production payloads, geographic effects, or account-specific data. Record the version actually serving each observation so a dashboard does not mix old and new responses into one reassuring average.

Define a minimum sample and observation duration before seeing the results. Zero observed errors in ten requests is weak evidence about a rare failure. If requests are independent with a fixed error probability, a binomial model connects sample size to possible observations. Real failures may cluster by user or payload, so inspect those slices too. Missing telemetry should block or explicitly qualify a promotion decision instead of silently being interpreted as zero failures.

A rolling Kubernetes Deployment manages replica replacement and availability constraints, but those mechanics do not by themselves establish application correctness. A progressive-delivery policy adds the team's decision rules around behavior. Decide whether each breach pauses for investigation or automatically returns traffic to the stable version. Use deadlines on analysis steps so the fleet cannot remain indefinitely in an expensive or ambiguous transitional state without an owner.

Test the abort path with an intentionally failing release in a safe environment. Verify that traffic moves, new errors stop, old capacity is healthy, and any background jobs or schema changes are handled. Record detection time and recovery time separately. Promotion should be an auditable decision tied to artifact identity and evidence, not a green button whose meaning changes between teams. A rollout experiment is complete only when its steady-state and failure behavior are both understood.