progressive-delivery

Progressive Delivery

Progressive delivery takes strategies covered in deployment-strategies — canary, blue-green — and makes the promotion decision automatic and metric-driven instead of manual or time-based. A canary that "runs for ten minutes then goes to 100%" is not progressive delivery, it's a timer with extra steps: if the ten minutes happened not to expose the regression, you ship it anyway. The controller (Argo Rollouts, Flagger) exists to query real signals at each step and decide, without a human in the loop, whether to advance, hold, or abort.

A canary step that isn't gated on a query against production metrics is just a delay, not a safety mechanism.

1. Pick metrics that would actually catch a bad release

The default temptation is to gate on whatever's easiest to query — often just HTTP error rate. That catches crashes, not the more common failure: a change that's technically 200-OK but slower, more expensive per request, or silently returning wrong data to a subset of users. Combine at least an error-rate metric with a latency percentile (p95 or p99, not average — averages hide tail regressions), and add a business metric when one exists and is fast enough to compute (checkout success rate, not daily revenue). See slo-definition for choosing thresholds that reflect what users actually notice, and metrics-and-monitoring for where these queries come from.

Done when: the analysis would have failed on the last real incident this service had.

2. Define the AnalysisTemplate as the actual go/no-go contract

The AnalysisTemplate (Argo Rollouts) or MetricTemplate (Flagger) is where "success" gets a precise definition — the query, the threshold, how many consecutive failures trigger a rollback, how many samples are required before a judgment is even made. Treat changes to this file with the same review rigor as the deployment manifest itself, because a threshold set too loose makes the automation theater, and one set too tight makes every deploy flap on noise.