Progressive Delivery

The pattern: do not promote a new version to 100% of traffic at once. Start with 1% (canary), measure success rate against a baseline, advance to 10%, 50%, 100% if metrics stay healthy; auto-rollback on regression. Variants: blue/green (full parallel deploy, switch traffic), feature flags (deploy code dark, toggle behavior later). Each variant trades different costs.

The trade-off: deploy velocity vs. blast radius. Big-bang deploys are fast but one bad release affects everyone. Canary/blue-green are slower (extra infra during the shift, more telemetry plumbing) but contain blast radius. Feature flags decouple deploy from release entirely — ship dark code, toggle on later, kill instantly. Modern platforms layer all three; the question is which dial each change deserves.

Deepens in Year 2 Phase 12: Platform Engineering (canary via service mesh) and Year 4 Phase 21 (model canary + drift-triggered rollback in KServe).

Related patterns

• gitops — the rollout controller reconciles git-declared rollout strategies, not just image tags.
• immutable-infrastructure — interchangeable instances are what makes blue/green and canary possible.
• platform-as-product — safe rollouts belong in the golden path, not in each team’s runbook.
• sli-slo-error-budget — the canary’s promote/abort decision is an SLI, evaluated against an error budget.
• three-pillars-and-unified-telemetry — automated rollback only works when telemetry is trustworthy.
• blameless-postmortem — when a canary catches a regression, the postmortem is about the gap that nearly let it through.
• Phase 12: Platform Engineering and basecamp — where progressive delivery becomes the default deploy shape.