Rod Johnson

Evolving understanding of software delivery

Two new terms have recently emerged around software delivery: Software Defined Delivery and Progressive Delivery. Why? How do they relate to Continuous Delivery?

Several forces today make delivery increasingly complex. Notably, proliferation of repositories, with hundreds of small projects replacing a handful of monoliths; desire for greater automation to realize the full potential of CD across multiple environments; the rise of feature flagging; and increased evidence (such as the Equifax debacle) of the need to bake security into the delivery process.

James Governor of RedMonk recently coined the term Progressive Delivery to capture some of these new needs:

I have been waiting for a term to emerge to describe a new basket of skills and technologies concerned with modern software development, testing and deployment. I am thinking of Canarying, Feature Flags, A/B testing at scale.

James is clear in acknowledging the critical prior art of Continuous Delivery: “CI/CD is the basis of everything good in modern software development.” Progressive Delivery refers to a set of newish problems and practices within Continuous Delivery.

In contrast, Software Defined Delivery (SDD) refers to an approach to solving these and other problems. How do we meet such new delivery demands? How can we iterate quickly to find the best solution for our team?

The core idea of SDD is simple: “Delivery infrastructure is now programmable, and we will program it.” Why should we continue to hack delivery pipelines out of YAML and Bash—a tactical solution to a strategic problem? Instead, we should approach delivery like any other engineering problem, applying our core skills and tools.

SDD recognizes that delivery should be:

  • Core: Delivery code is production code.
  • Engineered: In robust, testable code, just like our applications.
  • Collaborative: As people are part of the process and knowledge sharing is critical to success.
  • Accelerated: Through increased automation and reuse of components.

Together, these point to an extensible platform that can automate more than delivery. Anything we do repeatedly deserves to be automated. Instead of merely getting to fill in the blanks by configuring a CI application, we want to use our engineering skills and creativity against a rich model.

A recent tweet by Atomist’s Jessica Kerr highlights the benefits of using modern programming languages:

Progressive Delivery and Software Defined Delivery are complementary. Progressive Delivery describes needs that are becoming increasingly important in cloud native applications; SDD is necessary to meet these and other needs, and be able to continuously improve our continuous delivery.

Delivery is an engineering problem. By bringing our best engineering skills and practices to delivery, we can rise to new challenges as they appear, just as we overcome new business problems.

This article was originally published at by Rod Johnson. Rod is co-founder and CEO of Atomist, and creator of Spring.


Sign in or Join to comment or subscribe

Dave Karow

Dave Karow

Redwood City, CA

Build software faster without breaking things. Test what works (user behavior vs your opinion). Evangelist for Feature Flags tied to real time Metrics, enabling Experimentation

2019-03-26T20:31:06Z ago

Rod: I would argue that Software Defined Delivery is perhaps another way to say “Take your CI and deployment pipeline seriously” (i.e. treat it as your most important application).

Progressive Delivery is on my radar, because that’s one of the key use cases for Feature Flags.

Initial passes at Progressive Delivery used canary releases (an entire deployment pushed to a subset of servers, serving a subset of traffic). Recently, I wrote a piece making the case that Progressive Delivery is more useful if it’s implemented at the feature level (canary “release” features to a subset of users, not entire deployments to a subset of servers):

Player art
  0:00 / 0:00