09/12/2010

Continuous Delivery: How to deliver software to users at the click of a button

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 software such 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 Pipeline in which the entire system is recreated whenever a change is committed to the version-control system and provide continuous feedback

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.

Comments

You can follow this conversation by subscribing to the comment feed for this post.

Paul,

I understand and appreciate the benefits of having everything in version control, but what about projects that use Maven or a similar tool to download JAR files or other required artifacts automatically for them providing that a specific version of each of those artifacts are specified in a configuration file of some sorts?

On a related note, how do you setup developer machines? A problem I've faced in several occasions is that in our teams developer machines get out of sync -- some use version X of JDK, some version Y. Some use version V of MySQL, some version U, etc. etc. How do you tackle these problems?

There is a great video over at DevOpsCafe (Open Mic Episode 2) about how Wealth Front (formerly known as kaChing) is building and monitoring it's deployment pipeline. It's amazing how these guys push out dozens of code changes per day.