An Introduction to Progressive Delivery

As reported by DORA’s The Accelerate State of DevOps Report, elite performers deploy code to production a bunch of times a day,

The more you deploy a lot, the more likely you are to win the market, while it’s clear that most incidents are caused by code changes. Frequent deployments come with significant risk.

James Governor at RedMonk who invented the term Progressive Delivery says:

The elite performers are shipping a lot more code and with higher quality. – “An Introduction to Progressive Delivery”, James Governor at Qcon 2019

That is, what we want to end up with is a way to deploy a lot without breaking anything. I’d say Progressive Delivery is the closest solution to what’s being looking for, that’s why I will now walk you through what it is.

What is Progressive Delivery?

In a nutshell, it is a set of gradual deployments, analysis and automated rollbacks (as well as rollouts). This is obviously not enough, so let me take it a bit further.

This is an excerpt from Progressive Delivery in Kubernetes: Blue-Green and Canary Deployments written by Carlos Sanchez:

Progressive delivery is the next step after continuous delivery, where new versions are deployed to a subset of users and are evaluated in terms of correctness and performance before rolling them to the totality of the users and rolled back if not matching some key metrics.

I guess that explains it pretty well. That’s not only an overview, but also shows that it is Continuous Delivery++.

Here’s another short and coherent explanation:

Progressive Delivery is Continuous Delivery with fine-granted control over the blast radius.

Building blocks:

  • User segmentaition
  • Traffic management
  • Observability
  • Automation

– “Flagger: Istio Progressive Delivery Operator”, Stefan Prodan

I really like the expression “blast radius”, which is sometimes used to describe the range of failures.

Benefits

Testing in production

The main benefit for lots of people would be this. Automated rollbacks make it possible to perform tests in production with less risk. That lowers tha bar for finding bugs that have to be executed in a production environment to be found.

We often cannot completely simulate live, real-world software in a test and dev environment. Because of that, it’s been mentioned in a variety of places that production testing has become a necessary part of continuous delivery.

Accordingly, you can see Progressive Delivery allows us to release features quickly with minimal risk.

Beyond alpha thinking

We can now go forward and backward in our releases using automated analysis processes. That makes it much easier to release different versions for different regions and user segments.

That means Progressive delivery has the potential to take us beyond simple alpha, beta and GA thinking.

Wrapping up

While I didn’t describe the specific process, we are currently facing a few challenges. The main challenges I consider are:

The continuous delivery area is still a kind of chaos. I believe it’s a big step in the right direction to verbalize what many people have in mind. I hope to write about the elements that make it up such as analyses in the near future.

#devops