Progressive Delivery: A Detailed Overview

Every developer has been there before: You release a new feature expecting a smooth ride, only to have something go awry in the back end at the last minute. 

An event like this can derail a launch, letting down customers and leaving you scratching your head wondering what went wrong.

Suffice it to say that software development is very complex, and small issues can easily sneak through into production without detection. To avoid this, many development teams are now changing their vetting strategy and testing more during production using the progressive delivery model. 

Keep reading to learn the basics of progressive delivery and how it can help your company iterate with greater safety and efficiency—bringing more powerful products to market faster. 

In a traditional waterfall model, teams release new features to an entire user base at one time. Using progressive delivery, you roll out features gradually.

Here’s how it works: DevOps managers first ship a new feature to release managers for internal testing. Once that’s done, the feature goes to a small batch of users to collect additional feedback, or is incrementally released to more users over time. The final step is a general launch when the feature is ready for the masses.

It’s a bit like dipping your toes into the water before diving in. If something goes wrong during a launch, you haven’t exposed your entire user base to it. You can easily roll the feature back if you need to and make changes. 

Progressive delivery emerged in response to widespread dissatisfaction with the continuous delivery model. DevOps teams needed a way to control software releases and catch issues early on instead of pumping out bug-filled versions to their users, and progressive delivery met this requirement.

The idea stems from Microsoft’s progressive experimentation concept, which involves studying the blast radius prior to a product launch to determine how it will affect users. 

As the story goes, RedMonk co-founder James Governor took this concept and applied it to the continuous delivery model. Governor explains this in this compelling webinar on progressive delivery—a must-watch for anyone interested in learning more on the topic. 

It’s important to note that progressive delivery doesn’t replace continuous delivery. Rather, progressive delivery enhances continuous delivery and helps companies do it more effectively. 

There are several reasons why your company may decide to move beyond continuous delivery and embrace a progressive strategy instead.

As Governor explains in his primer, software development is shifting away from the idea of moving quickly and breaking things. Today, there’s growing interest in accelerating development pipelines—without breaking things. 

Companies want to take ownership of their code and deliver high-quality software. By incorporating rigorous testing into the process, progressive delivery enables you to ship large volumes of code at a higher volume without having to worry about frustrating the user experience. 

Progressive delivery lets you deploy new features to select user groups. This way, you can iron out any bugs and gather feedback before a general launch.

People tend to use software differently depending on their geographical location. Customers in Japan may approach an application in a much different way than customers in the US, for example. 

Developers need to take into consideration differing workflows, privacy restrictions, and language and cultural needs. Once again, progressive delivery helps here, too, by enabling you to discover needs and conflicts early on and make adjustments as you move forward. 

In his overview of progressive delivery, Governor makes a great point that people generally don’t like it when applications change. 

Google recognizes this, which is why the company lets users switch over to new features at their own pace, giving them time to process the change. This reduces pushback and also gives developers more time to collect feedback and make small improvements. 

With progressive delivery, you perform certain user tests during and after the launch. This ultimately saves time by enabling you to catch issues earlier. It prevents you from having to go back and make large structural changes deep in the production cycle.

Progressive delivery protects the customer experience by reducing risk. If a small user group has trouble with an update or is overwhelmingly against it, you can figure out why and decide how to address the situation.

By taking this approach, you can build customer trust while shielding the majority of customers from the messy development process.

One of the fundamental pillars of progressive development is progressive delegation. With this approach, a group of engineers first develops and tests a feature. After that, the software goes to a product manager, who conducts further testing and oversees the release. 

This frees developers to spend more time focusing on building and testing new features instead of refining code for release. It keeps pipelines moving, ultimately enabling companies to churn out features at scale faster. 

Testing tends to be dull, repetitive and time-consuming. Since talented developers want to spend their time creating and building, progressive delivery keeps teams engaged and reduces turnover.

A progressive delivery model gives teams multiple opportunities to catch bugs and vulnerabilities before a full release. Since it’s generally much cheaper to make changes early on in the development cycle, this strategy can save a lot of money over time. 

Progressive delivery brings together many different software development methodologies.

Here’s a breakdown of some key enabling elements.

A/B testing, or split testing, involves taking two versions of a piece of software and comparing how they perform. 

For example, you might release an app with two different interfaces and see how users respond. After collecting feedback, you can move forward confidently with the app that generates stronger results. 

Canary testing originates from the phrase “canary in the coal mine,” wherein miners would use a live bird to test for toxic fumes. 

With modern canary testing, you release code to a small group of users to see if it’s safe to release to a larger base. In this case, users act like canaries by testing the software. 

In a blue-green deployment, you set up two identical production environments: a blue and green one. One is live, and the other is for testing.

When it’s time to release a new software version, you swap the blue and green environments. This approach can reduce downtime and risk when rolling out a new service. 

CDRO tools enable rapid application delivery and help deliver better quality software. 

These tools introduce automation and monitoring throughout various stages of development, expediting testing and streamlining monitoring. With the right solution in place, you can manage your pipeline and environment more effectively while taking advantage of deployment automation and leveraging pipeline analytics to continuously refine your processes.

Observability is a control theory method for understanding a complex system. It involves using tools like logging, tracing and analytics engines to understand how services are performing and interacting. 

Through observability, it’s possible to determine whether you need to release an update to a group of users. Pairing user analytics engines with feature flag management systems can also automate the rollout or rollback based on pre-specified user criteria.

A service mesh is an infrastructure layer that sits over a container network interface (CNI) and contains a control plane and a data plane. Two popular examples include Istio and AWS App Mesh. 

This type of solution can enable user segmentation, traffic shifting management, observability and automation—all of which play a crucial role in progressive delivery. 

Feature flags, or feature toggles, are an important operational mechanism for progressive delivery. Flags let you control various functions during runtime. 

By deploying feature flags, you can turn features on and off for different groups of users. In this light, feature flags help control and limit deployments to select users. 

Thinking about implementing progressive delivery in your DevOps strategy? 

It’s a bold leap. But it’s one that could have a profound impact on the way your company handles software releases. Through progressive delivery, your team can tighten its grip on software production, collect more user feedback and catch errors before they slip into production. 

If you’re thinking about moving forward with progressive delivery, check out the CloudBees platform, which includes an advanced feature flagging mechanism that enables dev teams to target different users based on various attributes and manage who receives updates and when. 

For more information on how you can use CloudBees Feature Management to accelerate your progressive delivery efforts and build a smoother production environment, check out the documentation.

• Read the eBook: 5 Things You Need to Get Started with Enterprise Progressive Delivery