Dave Farley - Continuous Delivery Pipelines: How to Build Better Software Faster

Continuous Delivery emerged in the early 2000s, building on the techniques of Continuous Integration, and was popularised by mine and Jezs award-winning 2010 book Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation.

The term Continuous Delivery is taken from the first principle of the Agile Manifesto (2001), which states:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Continuous Delivery is the best way of developing software that we currently know of. It is the state of the art for software development, enabling its practitioners to deliver Better Software Faster. Teams that practise Continuous Delivery develop higher quality software, more efficiently, and have more fun while doing so. Businesses that employ Continuous Delivery have better staff retention, are more successful, and make more money.

We have research to back up these claims. Data from The State of DevOps Reports quantify the profound impact of Continuous Delivery on the effectiveness and efficiency of software development. For example:

44% more time spent on new features
50% higher market cap growth over 3 years
8000x faster deployment lead time
50% less time spent fixing security defects
50% lower change-failure rate
21% less time spent on unplanned work and rework

Its little wonder then, that some of the biggest, most successful software businesses on the planet practise Continuous Delivery. Companies like Amazon, Google, Netflix, Tesla, Paypal, and many more.

Continuous Delivery is achieved by working so that our software is always in a releasable state. But why is this fundamental idea so valuable to the development of quality software?

This way of working is the antithesis of traditional software development, where whole products, or systems, are developed over weeks and months, often with different elements being written by different teams, and brought together for a major release exercise: only then are defects and integration issues discovered, involving lots of rework, stress, delays, the abandonment of features, and disappointed customers.

Instead, through Continuous Delivery, we work in small steps, testing each tiny piece of new code as we proceed: incrementally building up more comprehenisve changes from these many small steps. Our aim is to commit each of these small steps as we make them, committing changes multiple times per day: all the time maintaining our software in a releasable state with each tiny change. This fast, dynamic, creative process means that we can make progress every day, avoid the problems of major releases, and have software that is always in a releasable state.

By working in small steps and making tiny changes frequently, we reduce the risk of complex interactions, compound errors and lengthy delays caused by rework.

There is only one definition of done - not partial or proxy measures suggested by other disciplines. The change is complete when it is delivered into the hands of its users.

Figure 1.1 - Idea to Working Software

Continuous Delivery is an holistic approach
Continuous Delivery encompasses all aspects of software development and is an holistic approach, which I define as:

going from idea to valuable, working software in the hands of users.

Continuous Delivery focuses on optimising the whole of that span and is therefore not only a technical discipline: it also requires optimal organisational structure and performance; and, an appropriate culture and ways of working. It includes the ideas of DevOps, collaboration and teamwork - where teams are empowered to make decisions and share responsibility for their code.