The art of moving fast but with control.

Article updated on 9/4/2024.

Organizations that employ Progressive Delivery ship code faster, reduce risk, and continuously improve the customer experience. Progressive Delivery is a key enabler of DevOps, and feature management is a key enabler of Progressive Delivery.

Some may understandably read this and say, “but wait, we’re not even doing CI/CD; now we have to adopt yet another methodology?” It’s a fair question.

The short answer is that Progressive Delivery gives you CI/CD at the same time. It provides safeguards and control levers that mitigate the risks of continuously pushing new code to a production environment. Progressive Delivery thus enables you to pursue CI/CD safely.

But how did Progressive Delivery come to be? What are its core tenets? What does it look like in practice? We'll answer these questions and more in this article.

Origins of Progressive Delivery

James Governor of RedMonk coined the term “Progressive Delivery” upon hearing Sam Guckenheimer of the Azure DevOps team explain Microsoft’s “Progressive Experimentation” model for feature rollouts. When James shared the idea with Adam Zimman, LaunchDarkly’s VP of Platform, Zimman realized that feature management would be a key enabler of this new Progressive Delivery model—a model defined by dark launches, feature flagging, testing in production, canary launches, blue-green deployments, A/B testing, and so on. James, Adam, and others have since begun evangelizing this new approach to software delivery.

Historical context of Progressive Delivery

In a 2019 panel discussion, Zimman, Guckenhemier, and Dr. Claire Knight of Github dissected Progressive Delivery from multiple angles. 

They traced the evolution of development lifecycles, starting with Waterfall and ending with Progressive Delivery. They recalled how in the days of Waterfall, developers would spend an entire year working on a software release. And despite all the painstaking effort, these big-bang releases still often caused errors in production.

Eventually, some organizations began embracing Agile principles and CI/CD. No doubt, these models have allowed teams to move faster, and they mark a big improvement over Waterfall. (At LaunchDarkly, we’re big proponents of Continuous Delivery.)

Nevertheless, the idea of shipping code to a production environment multiple times a day—in some cases, unfinished code—exceeds many companies’ risk tolerance. Software organizations, particularly in highly regulated industries, want to be assured that if they start shipping changes all the time, they'll have a way to shield customers from the failures that may occur at those high velocities. Better yet, they want mechanisms for delivering the right software changes to the right customers at the right time.

Ultimately, what they want is speed with control. And that is precisely what Progressive Delivery enables.

Core tenets of Progressive Delivery

Control is the bedrock of Progressive Delivery. This includes control over which users see which features, the timing of when engineers deploy changes to production versus when such changes get released to customers, and, lastly, who in an organization is allowed to release.

Zimman, Guckenheimer, and Knight discussed this notion of control in the context of two core tenets of Progressive Delivery.

1. Release progressions

This refers to adjusting the number of users exposed to (and impacted by) new features at a pace appropriate to your business. You can perform release progressions in a variety of ways—via targeted rollouts, canary launches, ring deployments, percentage rollouts, and so on. You might also think of a release progression as a progressive deployment/progressive release.

By creating more checkpoints for testing, experimenting, and gathering user feedback, release progressions improve the quality of each new feature. This, of course, elevates the quality of your product as a whole. (Note, LaunchDarkly’s feature management platform enables teams to perform release progressions in an easy, safe, and scalable way.)

2. Progressive delegation

This refers to progressively delegating the control of a feature to the owner who is most closely responsible for the outcome. A simple way to think about this is, initially, engineers control a feature. This makes sense, as they are responsible for building and testing it.

But once the feature has been tested, it makes more sense for a product manager (PM), for example, to control the process of launching that feature. After all, compared to developers, PMs are closer to the end-users for whom the new functionality is designed. In this scenario, progressive delegation entails giving PMs the ability to control the release experience. This, in turn, frees up engineers to go work on other high-priority projects. (Again, LaunchDarkly provides a simple user interface for facilitating progressive delegation.)

Here are examples of how Microsoft and GitHub put Progressive Delivery into practice.

Deployment rings at Microsoft

Guckenheimer explained that one of the ways Microsoft controls their releases is through deployment rings (or ring deployments). They intentionally divide users into groups, or rings, with each ring representing a different stage of a rollout.

Microsoft gradually rolls new features out to each ring, starting with ring zero (the canary group). Once they’ve tested the new functionality in production with the canary group and ensured that all the performance requirements have been met, they deploy the features to the next ring. The subsequent ring may include a sampling of data centers with a small user count, with the ring after that containing a sampling of data centers with a large user count, and so on. Generally, the stakes rise with each successive ring.

By requiring features to meet various performance criteria before moving onto the next ring, Microsoft dramatically reduces the risks of a launch. They limit the blast radius of any bugs that arise. Ring deployments, a technique of Progressive Delivery, thus gives Microsoft confidence to move fast.

“Staff ships” and canary deployments at Github

One way that Github progressively delivers software is through something called “staff ships.” Dr. Knight explained that Github employees use their own platform (Github) extensively. As such, they make a good canary group.

Using feature flags, Github will execute a “staff ship”, or canary deployment, in which they unveil new functionality to internal users while hiding it from the outside world. In this way, they can safely measure the feature’s effect on system performance as well as gather feedback on the user experience. And they can do this without disrupting customers.

Once the “staff ship” has run its course, Github releases the changes to external users. Progressive Delivery, and the tools and processes therein, takes the worry and stress out of releases. It empowers Github to ship as quickly as they please.

A final point worth making is that Progressive Delivery allows both Microsoft and Github to collect valuable data and user feedback on new features. Each leverages these insights to iterate on features, such that, after several iterations, the features perform much better than they would otherwise. All of this tends to result in happier customers.

Beyond the topics explored in LaunchDarkly’s Progressive Delivery webinar, there are several other facets of the new development lifecycle worth inspecting—for example, the relationship between Progressive Delivery and DevOps.

How Progressive Delivery enables DevOps

Among other things, the goal of DevOps is to increase deployment speeds, system stability, and cross-team collaboration. Progressive Delivery helps in all three areas. It provides safeguards and control levers that give development teams the confidence to deploy new code to production faster. These safeguards also assure operations teams that the increase in velocity will not compromise system stability. And finally, progressive delegation helps drive operational efficiency and foster greater collaboration among engineers and non-engineers in the software delivery process. In this way, Progressive Delivery fuels DevOps transformation.

As a part of their DevOps transformation, many organizations are adopting modern software engineering systems like Kubernetes and microservices. Thus, knowing how to implement Progressive Delivery in these environments is crucial.

Progressive deployments to Kubernetes in a microservices architecture

Given that Progressive Delivery is a modern software engineering practice, it makes sense that development teams would want to employ it in conjunction with their other modern tools. Teams commonly build cloud-native apps and deploy them to Kubernetes clusters within a microservices architecture. Here are a couple of approaches to progressively delivering features in this setting. 

1. Service meshes

If your application runs on Kubernetes within a microservices architecture, one way to engage in Progressive Delivery is through service meshes. This approach is essentially like doing a blue-green deployment.

You first create two nearly identical versions of your application, each tied to different production servers. Version A (blue) constitutes the old version of your application or service, while Version B (green) constitutes the new version with new functionality. You can then use a service mesh to run a canary test.

Using the service mesh, you route a subset of users, or your canary group, to Version B, and the rest of users to the old version. If the canary test succeeds, then the service mesh can route more users to the new version (traffic shifting), until finally moving all production traffic to the new version of the application. Conversely, if the canary test fails, the service mesh would route all traffic to the old version. Leveraging a service mesh for blue-green deployments is especially useful when making big infrastructure changes that usher in new dependencies, libraries, and so on.

Another effective way to perform canary launches, and to implement Progressive Delivery as a whole, is through feature management. Note, service meshes and feature flags are not mutually exclusive when it comes to enabling Progressive Delivery. In fact, they can complement each other quite well. When and how to use either a service mesh or feature management is up to your team.

2. Feature management: A key enabler of Progressive Delivery

Feature management is a new class of software development tools and practices anchored in the use of feature flags. Whether in a microservices architecture involving Kubernetes or otherwise, developers can use feature management to safely run canary deployments without spinning up multiple production instances of their application.

Feature flags give you fine-grained control over your deployments, in many cases, removing the need to change config files, do blue-green deployments, and roll back entire releases.

You wrap new functionality in a feature flag (feature toggle) and then deploy that new version of the application to a single production environment. This flag allows users in the canary group to access the new functionality, while barring the rest of your user base. If the canary test fails, then you can use a kill switch to toggle the feature flag to the ‘off’ position—no rollbacks or redeploys.

But if the canary test succeeds, you can continue rolling out the new app to additional user segments as a part of a broader ring deployment. Or you can do a percentage deployment. 

A feature management and experimentation platform like LaunchDarkly makes canary launches safe, swift, and seamless. But remember, canary launches are just one slice of Progressive Delivery.

LaunchDarkly enables software teams to implement all of the facets of Progressive Delivery. And it plays a crucial role in an organization’s Progressive Delivery strategy.

Automating Progressive Delivery

Developers can use LaunchDarkly to automate progressive rollouts with predefined, multi-step release paths. With Release Assistant, you can design release pipelines in which new features progress through an ordered set of environments—from local development to production—and follow targeting rules for each audience. Moreover, you can create release templates that automatically incorporate change approval requests, regulatory controls, and integrations with other critical tools in your DevOps stack.

Stay in control

The beauty of Progressive Delivery is that it has something for everyone. Risk-averse enterprises can use it to deploy as frequently or infrequently as they need to. The same goes for hard-driving startups and everyone in between. Progressive Delivery enables speed, to be sure. But it also gives you something perhaps even more transformative: it lets you release whenever and to whomever.

Ship fast, stay safe, and, at the very least, stay in control. That is the way of Progressive Delivery.