Progressive delivery is the logical next step for teams who have already implemented agile development, scrums, a CI/CD pipeline, and DevOps. It includes many modern software development processes, including canary deployments, A/B testing, and observability.
It is essentially a modified version of continuous delivery — in fact, before the term “progressive delivery”, many people called it “continuous delivery++” — with two core differences. First: progressive delivery teams use feature flags to increase speed and decrease deployment risk. Second: they implement a gradual process for both rollout and ownership.
Using Feature Flags for Progressive Delivery
The essential difference on the development side between CI/CD and progressive delivery is the use of feature flags. A continuous delivery team may do A/B testing, it may do blue/green deployments, it may implement DevOps or GitOps. But unless the development team is using feature flags, they’re not doing progressive delivery. At best, they’re doing really well at CI/CD.
The reason feature flags are so important is because they provide the opportunity for zero-risk deployment. By using a feature flag management system, even junior devs and new hires can push code to production: if the new version doesn’t work, you can rollback with the click of a button. With feature flags, you can test in production — not a very similar test environment, not a clone of it, but production itself. This means that not only do you get to use your real architecture, you also get to test on real users.
Some developers get antsy about this idea, but remember: you can roll back the feature instantly. So far as your users are concerned, you’re not causing a massive shutdown, but a trivial inconvenience. And this inconvenience is even further mitigated by the second aspect of progressive delivery.
Progressive Delivery Gradual Rollout Process
Good feature flag management systems provide extremely granular user targeting. This means software delivery teams have the ability to rollout to a small subset of users first, make sure it works, and if it does, gradually roll out to everyone else. So in stage 1, you release to the developers only; in stage 2, you release to a small set of users, and then if nothing goes wrong, you slowly release to more users until eventually you’ve rolled out to everyone.
This is useful because not only can you switch a feature off at any time, but you cause extraordinarily minimal inconvenience in the process. So not only do you cause only a trivial inconvenience to your users — you cause it to only 1% of them! This process of ensuring a minimal number of users are impacted by a failure is commonly termed “controlling the blast radius” of new features.
Gradual Ownership Change
Along with the process of gradually releasing a feature to more and more users, propagating it outward from the dev team, progressive delivery teams also propagate ownership outward. When a feature is first released internally, the dev team owns it, and is responsible for fixing any bugs that might be present. After its initial release to production, maybe the project manager owns it. And after it’s been released to all users, the customer success team probably owns it.
While some execute this process manually, the most successful teams automate the majority of this handover process, checking metrics and events to tell the system when to switch the release’s owner.
Gradual, and especially automatic, changes of ownership help to ensure the feature is always being tracked by the most appropriate team for the job. On initial release, the development team that built the feature should be monitoring it to ensure it’s working. After the feature is solid and released for everyone, the customer success team can answer user questions and gather feedback.
Summary
If you already have a great CI/CD pipeline, progressive delivery may seem trivial. But having a separate word for “continuous delivery with feature flags and canary deployment with gradual outward propagation of ownership” is useful, because this delivery process makes a major improvement on standard CI/CD. It creates an environment that not only fails quickly, but comes back from failure quickly. And given that no system is perfect, building your system to do well at handling failure is the next best thing.
