Skip to main content
progressive delivery

3 progressive delivery concepts everyone needs to understand

July 30, 2021
Reading time: 
12 mins

What is Progressive Delivery?

When introducing the concept of progressive delivery at QCon, James Governor, co-founder of analyst firm RedMonk, told how the industry lacked an umbrella term to describe a "basket of things" that fast-moving software companies use to ship great code.

He was looking for a single term to communicate these, and "progressive delivery" felt like the perfect shorthand.

While progressive delivery is often lumped with feature flagging, targeted service delivery and A/B tests, 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, continuous integration, continuous delivery, continuous deployment, and progressive experimentation.

In a recent Forrester survey, 43% of the respondents called experimentation "very important," and another 6% called it "mission-critical" for software development initiatives. Said another way: experimentation on the product development side enables businesses to build better software and compete on the product experience front.

So let's zoom in on how these staples of progressive delivery transform the way innovative companies deliver software, especially as it relates to shipping winning features.

1 Progressive delivery and feature flagging

At its simplest form, a feature flag is “if...else” logic. Feature flags (also called feature toggles or switches) give development and product teams granular control over which user or user group can access a feature or functionality, and when.

To understand the role of feature flagging in the context of progressive delivery and how it facilitates innovation, it's essential to look at how it works in the current software delivery pipeline along with continuous integration (CI), continuous delivery (CD), and continuous deployment (also CD!).

CI/CD & Progressive Delivery

Continuous integration is a DevOps best practice. Here, 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 builds upon continuous integration, taking the builds from continuous integration and delivering 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. Naturally, the testing team's bandwidth controls the release velocity.

In continuous deployment, in contrast, the new code (like a new feature or a bug fix or enhancement) 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. The end-users are the testers.

Both these almost-automated (continuous delivery) and fully-automated (continuous deployment) software delivery cycles work without feature flags. But, for innovative software businesses that compete on features, this isn't enough for various reasons. Three key considerations:

  • Feature development and code deployment are tightly coupled. Working on features in such a "continuous everything" development pipeline needs you to integrate, deliver, and deploy your feature code as you write it. There's no way to add your features to your system in an inactive state so that they don't impact the rest of it. This means you get less freedom when it comes to feature development. But with feature flags, you can easily control when your features are deployed. So you can ship features while they're still half-baked without causing a poor user experience — just keep the feature switch off.
  • It's high-stakes development. In continuous deployment (the one without manual testing), real users are the ones to detect the errors that creep through automated testing. If even a single high-severity bug gets discovered in any of your features or product experiences by a large population of your user base, your brand image gets hurt. This isn't to say that manual testing fields every bug, but this is riskier. With feature flags, you get granular control over who gets access to your features. With only a part of the population getting exposed to the new features initially, the risk is significantly lowered.
  • Either all features get launched or none at all. Without feature flags, you can't compartmentalize your code at the feature level. If you launch a group of features and one happens to be buggy, you'll still have to do a complete rollback. With feature flags, though, each feature gets its own switch. Simply toggling off the switch for a feature can kill it in the app, so you can target the buggy one.


By decoupling feature development from code deployment, feature flagging doesn't just help companies manage features better but also enables experimentation at the feature level, that too with real users using the live app. (More on this below.)

2 Deployment in progressive delivery

When it comes to deployment, again, progressive delivery uses the same deployments as standard software delivery.

Let's talk about canarying first. Traditionally, in canary deployment, you create an updated copy of your app and direct a small percentage of your traffic to it. Once you're satisfied with the canary's performance, you deploy the updated code to your production environment where all of your users can access it.

In contrast, blue-green deployment involves maintaining two identical production environments (blue and green). The green version is your live app or production environment, and the blue one acts as a staging environment. The blue version is the one where you apply your update. And when it performs satisfactorily and passes all the performance criteria, you start moving traffic 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.

Why use feature flags?

Both these deployments work without feature flags, but companies that compete on product experiences can find them limiting in their traditional setup (i.e., without feature flags). A few key considerations:

  • These deployment models don't offer control at the feature level. If you want to push the backend of a feature live in an app and test its performance without deploying the front end, you'd want to send the feature to the production environment in a disabled state (so that users don't see it). Blue-green deployment doesn't allow this by default. This becomes possible with feature flagging. In the case of canarying, if you want to test three new functionalities, you'll need to create three copies of your live app and route traffic accordingly. Feature flags can help avoid this. Combining feature flags with these deployment techniques gives you absolute granular control over how feature deployment happens.
  • Such deploying only gives you technical insights. In all fairness, these deployment techniques are designed for testing purposes and not for gaining business intelligence around the new features being launched. But for feature-first businesses, this feels limiting. It's crucial for such companies to learn how the features are really connecting with their intended audiences. They want to know if users are using it (feature adoption) and collect feedback in the interim too.
  • Targeting test users isn't possible in these deployments in the default setting. When performed without using feature flagging, both these deployments don't let you target specific user segments with specific features. For canarying, for instance, the testing cohort is a random sampling of about 1% of the user base. You can do some coding to route some targeted test traffic (like beta users), but that's the best you can do. This lack of control over feature accessibility limits how product teams can deploy features to a few select segments to gauge their popularity, discoverability, and adoption.


Again, both these deployment methods are only for finding bugs before releasing the software for all users. They aren't designed to gain insights or enable experimentation on the server-side, but businesses need these just as much.

3 A/B Testing for software 

Businesses that want to win on the experience front need to move fast. They need to consistently ship new functionalities. In a survey of software decision-makers, 97% said that they need to implement new features more rapidly. Accommodating concepts like DevOps, CI/CD, and continuous deployment allow for such high-speed software delivery cycles.

But in the same study, 67% of the respondents said that implementing new features safely posed a challenge. And 72% admitted that application development errors came at the cost of customers. The DORA report (2019) found that even Elite performers reported a change failure rate of up to 15% that resulted in degraded service leading to service impairment or service outage and subsequently needing remediation like requiring a hotfix, rollback, fix forward, or a patch. The change failure rate for low performers hovered in the 46% to 60% range.

The solution? Feature flagging.

Feature Flagging & A/B Testing

Feature flagging enables you to make continuous delivery safer by letting you control the user population that gets to access the new stuff and thereby considerably lowers the risk factor. That explains why 95% of businesses are either already implementing feature management via feature flags, have begun doing so, or are planning to do so.

But there's one more aspect to this. For product-led growth, businesses want to ship features users love. 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 know how features tie to business metrics that, in turn, reflect in revenue. They want to do more than just find problems with the code and capture business intel.

They want to "try" launching new features or differently implemented features and test them with real users. Feature flags allow running such experiments on the server side. With feature flags, your product team can unlock access to a new feature to a highly targeted user group and see if it gets upgrades. Or deliver a feature like a currency toggler on your checkout page (or even two completely different checkout experiences) and see which one gets more conversions and revenue, for instance. You get the drift.

Such experiments quickly collect user feedback and data and help product and dev teams loop them in when deciding about launching a feature (or experience).

In progressive delivery, features essentially have a new release cycle. 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 meet business goals.

Kameleoon supports progressive delivery with its Full Stack solution

With its powerful server-side A/B testing and personalization features, Kameleoon's Full Stack solution helps product and developer teams adopt and practice progressive delivery and feature experimentation. Developers? Learn how Kameleeon powers experimentation with feature flags on the server-side in our detailed documentation guide here.



Topics covered by this article
Stay up to date with our latest news..