Best practices for developing, building, deploying, and operating software have evolved significantly over the last two decades. Software delivery cycles no longer take 18 months, or even six months; it’s now just a matter of weeks, days, or even hours. Two of the biggest developments were the adoption of continuous integration and continuous delivery (CI/CD).  

This is a preview of the Progressive Delivery Patterns and Anti-Patterns Refcard. To read the entire Refcard, please download the PDF from the link above.

Continuous Integration

The original idea behind continuous integration was to find problems faster, and to get away from postponing problem discovery, merging issues, and identifying bugs until late in the process when they are harder to resolve. 

CI challenged people to focus on building smaller chunks of their solution at a time and to use mocks or virtual services so that each commit could be checked in on its own, and yet, they could still be tested and validated if other bits weren’t ready. 

Continuous Delivery

Then along came continuous delivery, the “radical” idea that deployments shouldn’t be labor-intensive, high-drama, multi-hour events that must happen outside of normal business hours. 

Continuous delivery sought to lower the cost (in time and talent) of delivering change. This goal of frequency and low drama required better ways to limit risk and observe the business impact.   

This is a preview of the Progressive Delivery Patterns and Anti-Patterns Refcard. To read the entire Refcard, please download the PDF from the link above.

Progressive delivery emerged as a natural response to concerns raised by the idea of “continuous” anything; if teams were going to move faster and release more often, then the surface area for things going wrong would likely be bigger. How could that be managed?  And better still, how could risk be reduced while simultaneously increasing the value of moving fast? 

The actual term was born out of a conversation between Sam Guckenheimer (head of product for Azure DevOps) and Redmonk Analyst, James Governor. Sam was describing Azure DevOps’ staged deployments around the world and how they used feature flags to gradually expose functionality to particular users. Sam called that practice “progressive experimentation”: 

“Well, when we’re rolling out services. What we do is progressive experimentation because what really matters is the blast radius. How many people will be affected when we roll that service out and what can we learn from them?” 

This is a preview of the Progressive Delivery Patterns and Anti-Patterns Refcard. To read the entire Refcard, please download the PDF from the link above.

Reduce Downtime 

We used to accept planned outages for “system upgrades” as mildly annoying but normal. Not anymore. No one enjoys logging onto a website to see a message declaring that the system is temporarily down for maintenance, or to launch a mobile app and find it mysteriously unresponsive. 

For services that are consumed by other services (such as credit card processing, shopping cart providers, and authentication providers), planned downtime isn’t just annoying, it’s simply unacceptable. This is the first goal of progressive delivery — to get away from bringing down an entire service just to install a new release. 

This is a preview of the Progressive Delivery Patterns and Anti-Patterns Refcard. To read the entire Refcard, please download the PDF from the link above.

Now that we have a better understanding of where progressive delivery came from and the goals it helps achieve, let’s move on to four common patterns for implementation and see how each helps us meet one or more of those goals. 

In this section, we identify four of the most common patterns for progressive delivery: blue-green deployments, canary releases, feature flag rollout, and feature delivery platforms. 

This is a preview of the Progressive Delivery Patterns and Anti-Patterns Refcard. To read the entire Refcard, please download the PDF from the link above.

Use the provided checklists to establish or extend the feature delivery platform pattern in your own environment. It is essential these capabilities be accessible to any member of your team. This should not require re-inventing the wheel by separate teams or ad-hoc investigation by a subject matter expert or “on-call” resource. 

Foundational Capabilities

Decouple Deploy From Release

Create a consistent, organization-wide mechanism for controlling exposure of new code:

• Allow changes of exposure w/o new deploy or rollback
• Support targeting by UserID, attribute (population), random hash

This is a preview of the Progressive Delivery Patterns and Anti-Patterns Refcard. To read the entire Refcard, please download the PDF from the link above.

When considering new ways of doing work, it’s useful to be clear on the “why” before figuring out the “how.” In this Refcard, we took the time to identify the goals for progressive delivery before exploring the available implementation patterns.   

Higher cadences of delivery simultaneously increase the chance for things to go wrong, but also the surface area for learning. Progressive delivery patterns are a proven way to reduce the risk of unforeseen consequences, and depending on your implementation choices, can increase the value of each release iteration.  

This is a preview of the Progressive Delivery Patterns and Anti-Patterns Refcard. To read the entire Refcard, please download the PDF from the link above.