Progressive Delivery - everything you need to know

What is progressive delivery?

Progressive delivery is a modern software development practice wherein a new feature is released to a smaller percentage of users to understand the impact of the update before rolling the feature out to 100% of the user base.

It builds upon continuous integration, continuous delivery, and continuous deployment (CI/CD) by using feature flags to control the release of features to particular user bases.

While progressive delivery is often lumped in with feature flagging, targeted service delivery and A/B testing, it encompasses the larger basket of iteration methods that tie into experimentation on the product side - which also includes canary and blue-green deployments, observability, DevOps, and progressive experimentation. 

Progressive delivery and the evolution of software development

To understand progressive delivery, it’s helpful to understand the evolution of software delivery methodologies. 

• Waterfall: marked by long build and test times followed by deployment. A single release could be worked on for several months at a time. It often ends up accruing significant costs while leading to failed releases.
• Agile: a more iterative process made up of a continuous cycle of building, testing, deploying, and releasing.
  • Continuous delivery/Continuous integration: teams build, test, and gather feedback several times before releasing a feature to minimize the effects of shipping the wrong product.
  • Progressive delivery: teams build, test, deploy, and release to a small subset of users to test the feature before rolling it out to the entire user base.

Progressive delivery is a way to build upon the CI/CD framework while mitigating the risk that comes with continuously releasing new code. 

The benefits of progressive delivery

Product managers can utilize progressive delivery to reduce the potential negative impacts of a release. Below are four of the top benefits of progressive delivery.

Faster feedback loops

Collecting and correctly acting upon user feedback is the mark of an innovative product team. Progressive delivery tightens feedback loops by making it quicker and easier to collect feedback on a new feature from users.

Product managers can release a new feature to a set of users during a beta trial, collect feedback on it, and make changes to that feature several times before releasing it to 100% of the user base. This can in turn improve product retention.

Decreased release risk

Traditionally, feature releases came with the risk of releasing a buggy feature, or a feature that was not used by users.

Testing a feature with a small set of users allows product managers to see if the feature performs as intended, and catch any bugs that may have slipped into production, before releasing it to the entire user base.

In doing so, this greatly decreases the risk of releases and reduces the possibility of having a major (and costly) feature rollback.

Increased agility and efficiency

Releasing a feature to users and then waiting for feedback before making changes leaves little room for iteration. 

Progressive delivery allows product teams to release a feature to a few select users, test it, iterate upon it, and release it again to another user base or the entire user population to test their hypotheses and assumptions.

By using feature flags, progressive delivery also enables developers to deploy code into a staging environment before it is ready to be released. This creates a more efficient development process.

More control over releases

CI/CD captures the importance of minimizing downtime and deploying software on a regular basis. However, with CI/CD, there is little control over who sees which features, and when features are released to a user base.

With progressive delivery, product teams have more control over their releases. In turn, they have more flexibility with how they release features to their users. 

How does progressive delivery work?

Progressive delivery is enabled via feature flags, an if/else logic snippet that can turn a feature on or off. They separate deployment from release, allowing product managers to release features if and when they choose without affecting a developer’s workflow.

Let’s say, for example, a product manager wants to test a significant feature with three subsets of users before releasing it to the general user base.

A developer will create a feature flag that can be used as needed. When the product manager wants to give feature access to a subset of users, they can simply enable the feature flag. This does not affect any of the other users' experience of the feature. 

If they need to turn a feature “off,” they can disable the associated flag.

Feature flags can be easily managed by any member of the product team using a Full Stack feature management solution.

Use cases for progressive delivery include:

• Canary testing
• Blue/green deployment
• Feature experimentation

We’ll explore each of these use cases further down below. 

Progressive delivery vs continuous integration, continuous delivery, and continuous deployment (CI/CD)

Progressive delivery is an evolution of the CI/CD framework. 

Continuous integration: developers continuously integrate the code they write with the live code. Automated tests validate the new code, and new builds get created automatically.

Continuous delivery: takes the builds from continuous integration and delivers them to a testing environment or a clone of the production environment (the live app or solution). 

Testing takes place manually, and the code is only deployed when the testers approve it. The testing team's bandwidth controls the release velocity.

Continuous deployment: the new code is posted to the production environment as soon as it passes baseline performance standards. There is no manual testing - the deployment happens automatically without any intervention from a developer or tester.

Progressive delivery: builds upon continuous deployment by implementing feature flags to separate deployment from release. Code is automatically deployed into the production environment, but is released gradually.

CI/CD is a beneficial evolution from previous software development methodologies. But for innovative software businesses that compete on features and innovation, implementing CI/CD is not enough to stay ahead. 

How progressive delivery addresses the problems with CI/CD

CI/CD poses some risks to agile product teams. Here are three problems with CI/CD that are solved with progressive delivery.

1. Feature development and code deployment are tightly coupled

Working on features in a “continuous everything" development pipeline requires developers to integrate, deliver, and deploy feature code as it is written. There's no way to add features to a system in an inactive state, resulting in less freedom when it comes to feature development. 

With progressive delivery, feature flags can be used to easily control when features are deployed. That way, features can be shipped and tested with certain user groups without exposing them to the entire user population.

2. CI/CD can be high-stakes development

In continuous deployment, users are the ones to detect the errors that creep through automated testing. This is problematic as a high-severity bug affecting a large number of users can greatly damage a brand’s image.

Progressive delivery allows for more control over who gets access to features and when. With only a part of the population getting exposed to a new release or feature initially, the overall risk is significantly lowered.

3. Either all features get launched or none at all 

With CI/CD, developers cannot compartmentalize code at the feature level. If a group of features is launched and one happens to be buggy, it still requires a complete rollback.

Progressive delivery uses feature flags so each feature gets its own switch. Simply toggling off the switch for a feature can kill it in the app or software, so a buggy feature can be targeted, without affecting the rest of the release.

Progressive delivery enables teams to make continuous delivery safer by controlling what user population gets access to what, thereby lowering the risk factor. 

Deployment in progressive delivery

When it comes to deployment, progressive delivery uses the same deployments as CI/CD. However, they’re made easier with the use of feature flags.

Here is how progressive delivery and the use of feature flags can improve canary and blue-green deployment.

Canary deployment (canary testing)

In canary deployment, an updated copy of an app is created and a small percentage of traffic is directed to it. If all looks okay, the updated code is deployed to the production environment where all users can access it.

By implementing progressive delivery with canary deployment, product managers can:

• Gain business intelligence around new features being launched.
• Target specific user segments with specific features.
• Deploy features to a few select segments to gauge their popularity, discoverability, and adoption.

Blue-green deployment

Blue-green deployment involves maintaining two identical production environments (blue and green). The green version is the live app or production environment. The blue version acts as a staging environment where the update is applied.

When the blue version performs satisfactorily and passes all the performance criteria, traffic is moved from the green version to the blue version. The blue version is now the live app, and the green one acts as the staging environment for the next release.

By implementing progressive delivery with blue-green deployment, product managers can:

• Push the backend of a feature live in an app and test its performance without deploying the front end.
• Have absolute granular control over how feature deployment happens.
• Collect feedback on how features are performing and how they are being used.
• Improve control over feature accessibility. 

Both these deployments work without feature flags, but companies that compete on product experiences can find them limiting in their traditional setup - hence making progressive delivery an integral part of efficient deployment. 

Progressive delivery and experimentation

Businesses want to ship features users love to enable product-led growth. In addition to de-risking the process of launching new features rapidly, they also need to validate the value of new or improved features. 

They want to do more than just find problems with the code and capture business intel. They want to know how features tie to business metrics that then reflect in revenue. 

Progressive delivery enables teams to experiment with launching new features or differently implemented features and test them with real users, also known as feature experimentation. Feature flags allow running such experiments server side. 

Teams can then quickly collect user feedback and data and use this feedback when making decisions that will affect the product or experience.

Embracing progressive delivery to a large extent means going from: 

• Design > Build > Deploy to
• Design > Build > Experiment > Deploy

By emphasizing the adoption of feature flagging, progressive delivery brings progressive experimentation to the traditional development mix. 

It allows businesses to move toward hypothesis-driven development where product and dev teams don't just think about requirements but take a scientific approach to build better product experiences that achieve business goals.

Kameleoon supports progressive delivery with its Full Stack solution

With its powerful server-side A/B testing, feature flagging and experimentation features, Kameleoon's Full Stack solution helps product and developer teams adopt and practice progressive delivery and feature experimentation. 

Kameleoon is designed to make every kind of experimentation easier for all teams: Users can run web, full stack, and feature experiments in a single unified platform. 

Kameleoon’s feature flagging capabilities make progressive delivery easier by:

Allowing product managers to determine when they want a feature to be released.
Defining a go-to-market plan with advanced scheduling options.
Setting alerts to roll back features based on goal performance or schedule.
Managing technical debt with Zapier triggers and actions.
Integrating with your existing tech stack.

Learn how Kameleoon powers feature experimentation with feature flags server-side in our detailed developer documentation guide.

Ready to learn more about Kameleoon? Book a demo today.