Progressive Delivery
Progressive delivery ramps a change from 0% to 100% in bounded steps with analysis at each, so a regression is caught at a small blast radius and the rollout halts before the full fleet is exposed.
Definition
Progressive delivery is the practice of releasing a change in increasing percentages — 1%, 5%, 25%, 100% — with automated metric analysis at each step, so that a regression is detected and halted at a small blast radius, combining canary, feature flags, and analysis into a single rollout pipeline.
Context and scope
Applied in continuous deployment, high-risk changes, and any system where an all-at-once release has an unacceptable blast radius.
Common misconceptions
- Progressive delivery is just canary — canary is one step; progressive delivery is the multi-step ramp with analysis at each, which is the generalization
- It requires feature flags — it requires a release gating mechanism; feature flags are one, but dark launch and routing weights also work
Anti-patterns
- Ramping to 100% without analysis at the intermediate steps, so a regression that appears at 25% is not caught until 100%
- Ramping so slowly that the partial state is visible to users for hours, trading blast radius for time-in-partial-state
Related concepts
Authoritative source
What it is
Progressive delivery is the practice of releasing a change in increasing percentages — 1%, 5%, 25%, 100% — with automated metric analysis at each step, so that a regression is detected and halted at a small blast radius, combining canary, feature flags, and analysis into a single rollout pipeline. Applied in continuous deployment, high-risk changes, and any system where an all-at-once release has an unacceptable blast radius. The unit of delivery is the deployable artifact plus its configuration, and the goal is to move changes to production safely, quickly, and reversibly.
How it works
Safety comes from small batches (less change per deploy means less blast radius), automated canaries (a bad change is caught at 1% before it reaches 100%), and reversible deployments (rollback is the default escape, not a rewrite). Speed comes from pipeline parallelism and eliminating the manual gates that batch up changes. Every step produces evidence — test results, scan output, canary metrics — that the next step consumes.
When to apply and pitfalls
Apply whenever the cost of an incident exceeds the cost of the pipeline that prevents it. The pitfall is optimizing deploy speed without investing in the observability and rollback that make speed safe — fast deploys of broken code just reach the outage sooner. Another is treating the pipeline as a checklist rather than a feedback loop that improves with each deployment.