[]

Continuous Delivery * part of the Martin Fowler Signature Series – was published last month and if delivering software to your users quickly and often is important to you, you must get this book. Continuous Delivery is what we provide our clients at Stelligent * delivering complete software systems to users at the push of a button. Jez Humble and David Farley go into great detail in describing everything you need to do to create a continuous delivery system. 

This is one of the most important software books published in years. From the beginning and throughout the book, the authors emphasize the importance in establishing one delivery team consisting of various experts throughout the software lifecycle – developers, DBAs, Systems/Operations, network specialists, testers and so on. The overarching pattern the authors describe is the Deployment Pipeline, which is basically a staged process consisting of all of the steps to go from bare/virtual metal to a working system whenever there is a change to source files. Of course, the only way this can be done is through copious amounts of automation. The other key point the authors make is that this automated delivery system – itself – is versioned with every change. Not just the custom source code, but also the operating system(s), tools, configuration and everything necessary to create a working software system. It’s the first book I know to describe this concept in such great detail and not (really) provide any exceptions to the rule. In Continuous Integration (also in Fowler’s series), I made a point of putting ‘everything’ in version control (referring to Berczuk and Appleton’s Repository pattern), but Humble and Farley made it a core theme of their Deployment Pipeline and the overall book.

To sum up the book in a few bullets:

• The purpose of Continuous Delivery is to reduce the cycle time between an idea and usable softwaresuch that it’s approaching zero
• Automate (almost) everything necessary to create usable software
• Version complete software systems (not just source code) for every change committed to version control system
• Employ a Deployment Pipelinein which the entire system is recreated whenever a change is committed to the version-control system and provide continuous feedback
• Identify one delivery team consisting of various delivery experts – build, deploy, provisioning, database, testing, etc. – a concept emphasized in the DevOps movement

The authors go into great detail in describing each of these themes. So, if you want the process of delivering software to any target environment – including production – to be a click of a button and something that can be accomplished as often as the business requires, get this book. When you employ the practices in this book, no longer will you need to artificially throttle changes delivered to users for months or even years because of the expense and risk required to deliver software.

As a note, I plan to extract and describe a combination of patterns from this book, the Continuous Integration book, and other patterns we use at Stelligent in upcoming blog posts.