Progressive Delivery

Elite software development teams share this in common: they’ve all mastered Continuous Delivery.

Companies like Amazon, Google, and Netflix get small changes—features, bug fixes, etc.—into production or users’ hands thousands of times a day.[1] [2]
They move fast, yes. But they also learn fast.

Each change generates data on user engagement, system performance, and other key metrics. This data, in turn, fuels a virtuous cycle of iteration, wherein the quality of the product constantly improves. In this way, elite companies reap the benefits of Continuous Delivery.

Despite the clear benefits of this approach, many large organizations are still reluctant to adopt it. Why?

For one thing, Continuous Delivery often implies shipping incomplete code. That’s a scary proposition when talking about a production environment for millions of users. Moreover, it embraces the reality of bugs and small system failures. It accepts that some application changes will inevitably cause problems.

And such problems are acceptable, so long as they happen early and on a small scale.

[1] Companies that deploy hundreds or thousands of times a day often are engaging in Continuous Deployment in addition to Continuous Delivery. This means they have automated the deployment process. Whereas, Continuous Delivery entails keeping code in a deployable state at all times but does not refer to automatically deploying code once it’s been committed. But, of course, code deployments cannot be automated unless the code is in a deployable state. All that to say, when a team engages in Continuous Deployment, it’s implied that they also are doing Continuous Delivery.

[2] Forsgren, Nicole, Dr., Frazelle, Jessie, Humble, Jez, Smith, Dustin, Dr. “Accelerate: State of DevOps 2019.” DevOps Research & Assessment, Google Cloud. 2019: 22.

This approach contrasts sharply with the Waterfall delivery method, in which developers toil for months, or years, on a set of features before finally shipping them in one big heap. Many teams cling to this approach because, in their minds, it allows them to retain control over the deployment process.

Of course, Waterfall attempts to provide such control by reducing the deployment and release frequency. And in any case, such control is an illusion given how frequently bugs still occur in a Waterfall context. Nevertheless, Waterfall practitioners fear that Continuous Delivery will rob them of their sense of control.

Early proponents of Continuous Delivery introduced techniques to quell such fears. Practices like blue-green deployments, canary launches, and ring deployments[3] enable teams to continuously deliver in a controlled manner. But many teams either don’t know about these techniques or fail to employ them.

Moreover, while such practices were born in a Continuous Delivery context, they were not stressed as heavily as other aspects of the methodology. As a result, large organizations are left with the false impression that Continuous Delivery is dangerous.

Other practices have since emerged that build upon the initial riskreducing techniques. Collectively, these techniques are like different strands of the same rope, all aimed at giving teams greater control when delivering software. When woven together, they become a new approach to software delivery, one that iterates on Continuous Delivery and that is essential to modern software development. Enterprises gain the control they desire and thus pursue the core benefits of Continuous Delivery safely, at their own pace, and on their own terms.

We call this new approach Progressive Delivery.[4]

[3] Jez Humble discusses deployment rings and limiting impact in his book Continuous Delivery.

[4] Teams at IBM, Microsoft, and Target have written and talked about how they are making Progressive Delivery (sometimes referred to as “Continuous Delivery ++”) work for them. Microsoft has been speaking about this approach for a while and helping teams adopt the right tools to benefit from this approach. James Governor of RedMonk was one of the first to popularize the term “progressive delivery"