Continuous Delivery

Written by Jorrit Tuesday, 07 December 2010 21:48

Jez Humble and David Farley share their many years of combined experience in their new book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Humble and Farley give a great overview of all the elements that need to be considered when one wants to build a proper software factory for continuous delivery. This book’s value is that it bundles everything in one place. Because of this, testers, managers and developers would all find the book an interesting read; I fully recommend it.

One of the clear messages of the book is: invest time and energy in a proper version control system. I couldn’t agree more. Lack of, or an arcane version control system, kills productivity and is a source for frustration.  It’s quite unbelievable that, in 2010, this is not common knowledge.  This book at least does its bit to change this silly status quo.

Assuming you have set up version control, the next step is Continuous Integration (CI), where the code is automatically compiled and tested upon every commit to the source repository. To be able to test the code...tests need to be written. Ideally, this is done during development using Test Driven Development (TDD), but, as long as all code has unit tests, the CI server can check if all code integrates and works as expected. Humble and Farley give guidelines of the amount of code coverage you should aim for to be reasonably confident that the code is correct. Since it makes little sense to have CI in place without tests we usually introduce TDD first, especially on legacy projects. The authors are right though, CI is never far behind. A proper CI setup can also help with building up the test suite, for example by only accepting code commits with higher coverage than the last successful build.

User Acceptance Testing is the next step in the delivery line. The authors suggest various tools that can be used to capture user acceptance tests. The tool should run automatically once your code has been successfully built and unit tested against the compiled artefacts (EXE, DLL’s, JAR’s or whatever the equivalent is for the technology you are using) created during the commit step.

Having tested that your artefacts are correct technically and functionally it’s time to package everything up and get the code ready for shipping. Again, many tools will do the job, but pick one that will allow for complete automation of the process. Computers are great at repetitive work, humans not so, that’s to say, never send a man to do a machine’s job.

Testing against the packaged product is a very diverse topic, since this widely varies with the kind of application, which is well covered in the book. Testing GUI’s can be somewhat of a hassle, the practical advice offered here can be very helpful when deciding which part of the the job to automate and how.

In the last chapter, the authors offer a maturity model to gauge where a project or organisation stands on its road of creating continuous delivery. This is a very useful tool to help to determine where one stands and deciding on process improvement goals. This model will definitely go in my toolbox as I am sure it will come in handy some day.

In summary, this is a great book that bundles all the knowledge you need to seriously consider setting up a proper software factory without getting caught in too much detail. That is it gives clear advice on where to start and which steps to take to keep the improvement process going. In addition, the authors provide you with the tools needed to make a convincing argument for continuous delivery.

Further Reading
Before Continuous Delivery, many finance companies start with a good old fashioned smoke test.