Breaking the Link
Think about a restaurant opening a new dish. The chef can cook it in the kitchen (deployment) without putting it on the menu yet (release). They might serve it only to staff first, get feedback, tweak the recipe, and only then add it to the menu for all customers. This is exactly the mental model behind Progressive Delivery.
For a long time, "deploying" code to a server and "releasing" a feature to users were the exact same thing. Once the code landed on production servers, everyone could see it. This made deployments scary events often scheduled for nights or weekends, with entire teams on standby ready to roll back if something went wrong.
Progressive Delivery is a set of practices that breaks this link permanently:
- Deployment is a technical act: moving a new version of an application's artifact (like a Docker container) onto infrastructure. The code is on the servers, but no user necessarily sees it.
- Release is a business act: exposing a new feature or version to end-users. This is a deliberate, controlled decision made independently of deployment.
By separating these two events, teams gain immense control. You can deploy code on a Tuesday afternoon during business hours — with no stress — and keep it hidden from users until a major marketing launch on Friday. Deployments become routine, boring, and safe.
The Goal: Control the Blast Radius
The core idea of Progressive Delivery is to expose new changes to a small, low-risk audience first. You validate that the changes are correct and stable, and only then do you progressively expand the audience until everyone has the new version.
If something goes wrong, only a small percentage of users are impacted, and you can instantly cut off access to the bad feature. This turns a potential catastrophe — a full production outage affecting every user — into a minor non-event affecting 1% of traffic for a few minutes.
The three primary mechanisms of Progressive Delivery are:
- Feature Flags — code-level switches that control who sees what functionality.
- Canary Deployments — routing a small percentage of real traffic to a new version.
- Automated Canary Analysis (ACA) — using statistical engines to make promotion/rollback decisions automatically.