Progressive delivery: The future of software development: faster delivery with less risk

August 9, 2021

iauro Team

Contributing immensely to the global software solutions ecosystem. DevOps | Microservices | Microfrontend | DesignThinking LinkedIn
Today’s technology world is far more advanced, experimental and playful than it was when corporate technology ruled everything. And, naturally, the Internet has played a key role in this transformation, which extends to the DevOps dynamics that drive product growth and distribution. Today we operate in a multi-platform, multi-cloud, hybrid world where deployment goals and routes must be flexible and dynamic.

Until now, Continuous Integration / Continuous Delivery (CI / CD) has been the focus of DevOps Services, driving the modern software development industry forward. However, the current and future needs of the industry require new methods that make the deployment process progressive.

Progressive Delivery is exactly what you need!

Using a blended set of technologies and skills to test and deploy software development – A / B testing, feature flags, blue-green deployments, and canary, to name a few – is transforming the approach to service and application delivery.

And all this to the point that deploying a service doesn’t necessarily mean releasing it.

Fast movement with control

Progressive delivery refers to a new software development lifecycle that is being deployed to deliver code faster and with less risk. Thus, we always improve the quality of customer service. In essence, it is an extension of the core principles of CI / CD, equipped with protections and controls that exponentially reduce the risk of continuous code adoption in production.

Thus, control is at the heart of progressive delivery. This control extends to features that users can see when the engineers made changes, and the authority to release features. To ensure that this element can be completed quickly without losing control, Progressive Delivery relies on two main principles:

Release progressions

Adjust the number of users who access new features at a pace that suits your business. This control can be done with percentage deployments, ring deployments, canary launches, or targeted deployments. This makes it easy to create multiple checkpoints for experimentation, testing, and absorption of feedback. These elements can then be used to improve the quality of each new feature – and therefore the entire product.

Progressive delegation

This entails a gradual, phased delegation of control over the new function. Simply put, initially, control of a feature rests with the engineers tasked with creating and testing it. Once tested, it can be handed over to the product manager in charge of launching the end-user feature. The product manager then oversees the release process, allowing engineers to focus on product development and testing for other projects.

The versatility of Progressive Delivery makes it suitable for all types of users, even those who have not implemented CI / CD into their processes. Once deployed, it can be deployed as often or periodically as the enterprise sees fit.

Evolution of progressive delivery

To understand the evolution of progressive delivery, one has to look back at the evolution of software development lifecycles, dating back to the waterfall days, when software developers spent months developing a product. Despite the careful and meticulous approach, the products were often far from perfect.

Agile principles followed, followed by CI / CD. These models have changed the speed and accuracy of software development, testing, and release. As the technology ecosystem becomes more dynamic, even an advanced approach like CI / CD is missing something.

Then, speaking at QCon in London in 2019, RedMonk founder James Governor came up with the idea of ​​increasing system resilience through progressive delivery. He aimed to reduce the risk associated with a delivery code – often incomplete – multiple times a day. Software companies wanted a safety net to protect their users from the high risk of disruptions associated with frequent delivery of changes.

More importantly, they were looking for a system that could provide customers with the right changes at the right time. This is exactly what progressive delivery offers.

Using a combination of A / B testing, feature flags, Canarying, Istio service mesh, and Kubernetes, Progressive Delivery allows you to create a sophisticated routing system for new application features for end-users quickly and securely without losing control.

The need for progressive delivery

Progressive delivery allows you to deliver any changes to a select group of low-risk audiences, measure their response, and make changes if necessary before moving to a wider user pool. For example, a target group of 1% of the total user base is first exposed to any new changes. This pool is then expanded to 5-7% before making changes to the entire user base.

In case the changes are not well received by users, they will only affect 1% or 7% of traffic and revenue, not 100%. This system works on the principle of managing two relevant factors – the environment and users. Tools like blue-green deployments or canary builds are used to limit exposure to new changes.

All the leading tech giants, be they Google, Microsoft, Facebook, or Amazon, are already rolling out Progressive Delivery, releasing any new products or features to a small market or percentage of users in the market to gauge how well received they are.

For example, Microsoft relies on ring deployment to manage its releases, dividing different groups of users into groups for different phases of deployment. They start by testing a new feature with a canary group or zero links. Only after all performance metrics in the canary group are satisfactory do they deploy the feature to the next group or ring and into the next.

Likewise, Github uses feature flags to present its new feature to internal users before exposing them to the world. Only when a new feature satisfactorily meets the performance parameters for this selected group is it deployed to the rest of the users.

By incorporating user feedback and valuable data, progressive delivery provides actionable insights for improving functionality and features.

Key elements of progressive delivery

The progressive delivery system is built on a well-structured network. Some of the key elements:

Canary testing:

This means releasing any new change or feature to a small group of users. This allows you to quickly check the impact and effectiveness of the change, as well as the willingness of users to accept the change. Because canary testing allows new code to be deployed to a small subset of users (often 1–5% of the total user base), server traffic can be carefully monitored to assess performance and uncover unexpected problems. In this sense, it can be considered a more subtle version of the blue-green deployment method.

Blue-green deployments:

In this deployment method, any new change functionality is first deployed to one production environment (blue). After verifying its effectiveness in this environment, it is transferred to another environment (green). Only one of these environments is alive at a time. It serves as a testing ground for changes made, providing a quick rollback in the event of any failure. By using two identical production environments, downtime and risk can be effectively controlled.

Feature flags:

Feature flags or toggles make it easy to enable, disable, or hide certain features in the user interface. This progressive delivery element helps you test changes and new features with a select group of users before making them available to a wider audience.

A / B testing:

This is used to test different versions of a change on different groups of users, and then to evaluate which one performs better. A / B testing is most often used to test the usability impact of any change, which in turn can impact conversions.


This element is focused on assessing management in a production environment using parameters such as metrics, tracking, and logging. This is a departure from traditional monitoring methods in the software world. As the name suggests, observability is looking for answers about the performance of a system by simply observing it from the outside. In progressive delivery, this means answering questions without having to submit a new code.

Service Mesh:

The service grid, placed between containers and services, logs what last worked. This helps to revert to a previous answer if the new change doesn’t work. The service grid is responsible for providing user segmentation, traffic switching management, metrics maintenance, and observability. By controlling these elements, it allows users to precisely control the blast radius.

Chaos Engineering:

Chaos engineering is all about embracing failure by determining the normal state of the system and then using actual resistance testing to fix problem areas. This allows businesses to conduct controlled experimentation on their digital products and services during development, testing, and incremental delivery. Developers and delivery teams can proactively remediate gaps, issues, and SLA violations with minimal downtime. This not only helps to contain the negative impact of any disruptions on the business but also gives them confidence that their systems are equipped to perform optimally in the real world.

Benefits of progressive delivery

Progressive delivery gives your development team control over the deployment process. This provides the following benefits:

Quality control:

Through elements such as chaos and service grid, Progressive Delivery allows developers to maintain quality control even during feature deployment. By controlling the environment in which a new change is first released, you also gain control over the quality of new features in the production environment.

Anticipating failures:

When any new change is deployed in stages using canaries or feature flags and its functionality is tested every step of the way, any functionality issues based on the experience of a small number of users can be noted and fixed.

Updated changes:

Based on user feedback on new features or functionality, any changes that don’t work can be quickly undone or corrected.

Reduced risk:

Since developers have complete control over the deployment process, this reduces risk and promotes greater focus on development.

Delegating control:

The gradual delegation of control over any new function places the task of releasing in the hands of product managers or other non-engineering professionals. This allows developers to move quickly to other high-priority projects.

Accepting failure:

Through the chaos of engineering, Progressive Delivery not only empowers developers to anticipate failure, but also to accept, account for, and quickly fix them with real-world resistance tests.

Reduced downtime:

In a recent study, Expedia linked the new changes to two-thirds of its outages. Through the deployment model, Blue-Green Progressive Delivery minimizes annoying downtime or no response.

Best Practices for Implementing Progressive Delivery

The progressive delivery system was conceived to roll out new updates or features without losing control over the impact of the change. For example, if a new code is released, each new unit subject to this change becomes part of its blast radius, creating a ripple effect that carries the original impact forward.

In this ecosystem, Progressive Delivery acts as a valve that can decouple code deployment from release, thus controlling its trajectory when and when it becomes available to end-users. To make it effective, points of validation and control must be based on feedback and data-driven insights.

To use this cultivated approach to optimize the continuous delivery pipeline, the following techniques are needed:

User segmentation:

Dividing your user base into different groups or canaries and gradually adding features in a controlled manner. First to your internal team, then to beta testers, then to a selected market or user group within a market, before opening it to your entire user base.

Traffic control:

Progressive delivery should also be used to control which section of your traffic you are subject to any new changes. This allows you to limit backlash in the event of errors, performance spikes, or rollbacks. If you find an issue where the deployment is 1% of your traffic, you can stop the change in its tracks. So you only negatively impacted 1% of your user experience and possibly revenue, rather than 100%.


You don’t use progressive delivery until you make your processes more robust. By using the various elements of this system to create a structured delivery process, you can not only reduce risk but also define the best user experience through iteration.

Slow deployment:

Users usually resist any changes to the interface of the application because it makes it difficult to familiarity and usability. For example, when Google tweaks Gmail’s features, we don’t like it right away. But by allowing users to adapt at their own pace, Google is making the transition easier. This slow deployment, combined with a gentle nudge through constant reminders, is a smart approach to leveraging progressive delivery effectively.

Progressive Delivery is poised to change the DevOps ecosystem. Skeptics may call it CI / CD 2.0, but the bottom line is that this system will drive future changes based on data analysis and understanding of your audience’s experience. It’s all about shifting the focus from ceremonies to small, significant, and permanent changes. Mastering this today means preparing your team for the futuristic wave of the product journey.


Submit a Comment

Your email address will not be published. Required fields are marked *

Subscribe for updates