Continuous Delivery

In the late 90's I paid a visit to Kent Beck, then working in Switzerland for an insurance company. He showed me around his project and one of the interesting aspects of his highly disciplined team was the fact that they deployed their software into production every night. This regular deployment gave them many advantages: written software wasn't waiting uselessly before it was used, they could respond quickly to problems and opportunities, and the rapid turn-around led to a much deeper relationship between them, their business customer, and their final customers.

In the last decade I've worked at Thoughtworks and a common theme of our projects has been reducing that cycle time between idea and usable software. I see plenty of project stories and they almost all involve a determined shortening of that cycle. While we don't usually do daily deliveries into production, it's now common to see teams doing bi-weekly releases.

Dave and Jez have been part of that sea-change, actively involved in projects that have built a culture of frequent, reliable deliveries. They and our colleagues have taken organizations that struggled to deploy software once a year, into the world of Continuous Delivery, where releasing becomes routine.

The foundation for the approach, at least for the development team, is Continuous Integration (CI). CI keeps a development team in sync with each other, removing the delays due to integration issues. A couple of years ago Paul Duvall wrote the book on CI within this series. But CI is just the first step. Software that's been successfully integrated into a mainline code stream still isn't software that's out in production doing its job. Dave and Jez's book pick up the story from CI to deal with that 'last mile', describing how to build the deployment pipelines that turn integrated code into production software.

This kind of delivery thinking has long been a forgotten corner of software development, falling into a hole between developers and operations teams. So it's no surprise that the techniques in this book rest upon bringing these teams together, a harbinger of the nascent but growing “devops” movement. This process also involves testers, as testing is a key element of ensuring error-free releases. Threading through it all is a high degree of automation so things can be done quickly and without error.

Getting all this working takes effort, but benefits are profound. Long, high intensity releases become a thing of the past. Customers of software see ideas rapidly turned into working code that they can use every day. Perhaps most importantly we remove one of the biggest sources of baleful stress in software development. Nobody likes those tense weekends trying to get a system upgrade released before Monday dawns.

It seems to me that a book that can show you how to deliver your software frequently and without the usual stresses is a no-brainer to read. For your team's sake, I hope you agree.