Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Jez Humble, David Farley (2010)
Review date: March, 2012

The first chapter sells the main message of the book: make frequent, automated releases. Chapter two, on configuration management, stresses the importance of having everything under version control and gives pointers about how to deal with different types of configuration.

"Continuous integration", chapter three, is a neat summary of continuous integration ending with some pages on distributed version control systems. The last chapter of the first part is pretty much covering Brian Marick's testing quadrants with some additional material on integration and acceptance tests.

Part two is dedicated to the central concept in the book - the deployment pipeline, so its first chapter is a little taste of what's to come. The next chapter talks about build scripting. A big part of it is devoted to explaining how build tools work and going through individual tools. Things get more specific towards the end of the chapter. Chapter seven is about the "commit stage", and focuses on the tests you would want to do there.

Chapter eight is on automated acceptance testing. It explains how to design stable automated acceptance tests and how they are structured. The next chapter is about testing non-functional requirements, but in practice it's about capacity testing. The last chapter of the section is about the release, and talks about different ways to actually release to production, about pitfalls and rollback.

The last part is about the remaining details needed to make everything glue together. Chapter eleven, on infrastructure, sells automated provisioning and virtualization (as well as some cloud). The next chapter gives a short overview of data management and database versioning. While chapter 13 and 14 are quite technical and deal with components and version control, the last chapter takes a wider perspective and puts everything in a larger context.


This book was very hard to review! I had to return to writing the review at least three times. Normally, I always write in one go. What made this case particularly difficult was the fact that every single chapter would require a review of its own.

It doesn't take many pages of reading to realize that the authors are very knowledgeable. The book covers a very broad field, and the reader can tell that it's based on true war stories and hard-earned experience. As said above, continuous delivery is huge topic and taking it on is a challenge. It's impressive to see that somebody has done it. Readers who have experience in actually implementing the techniques described in the book will be delighted. They will see variations of what they have been doing and some theory to go along with it.

On the other hand, readers who haven't tried a certain technique or haven't worked in a certain area may be disappointed. Due to the size of the topic, the book cannot go into too much detail. Doing this would easily triple its size. So what sometimes happens is that the devil that's lurking in the details is totally left out. The consequence of this is that some non-trivial topics appear very easy.

Personally, I've worked with many of the techniques described in the book, but there were certain passages that I couldn't translate to a workable solution. Pinned, static, and fluid dependencies, as well as the exact details of a complex build pipeline are still a mystery to me. Maybe I should have followed up on the references.

This is pretty much my only critique: sometimes another layer of detail wouldn't hurt. No specific examples, no source code or scripts, just some more detail. A good example of this is chapter 12 (this happens to be a topic with which I'm quite familiar). A lot of ground is covered in not too many pages, and when the dust has settled you don't really feel that enlightened. There are other chapters or sections that leave question marks behind as well.

I feel that it's quite meaningless to pick up and analyze individual statements or points of view. There are too many. Nevertheless, I picked some favorites:

The messages of the first chapter: "Manual deployment is an anti-pattern". "If it hurts, do it more frequently". This really tells what the book is all about, and everybody who has been through the hassle of manual deployment and its companion rituals will be hooked at this point. It's a very good introductory chapter that really makes you keep reading.

Throughout the book, there are some chapters that are very good summaries of larger topics that usually have their own books. Continuous integration and testing (strategies) are treated in this way, and readers who have deep-dived into such material will find the summaries sufficient and concise. There are also short descriptions of build tools and version control systems. I haven't seen such summaries/overviews so far, so I found them interesting.

The chapter on components is very interesting and treats a difficult topic. What I liked the most here was a simple phrase, just caught in mid-sentence: using components doesn't imply an n-tier system. How I wish that some architects had these words printed, framed and hung on the wall.

Branching is an interesting and touchy subject, and this happens to be the first book I've read that takes it on systematically. Different kinds of branching strategies are explained in detail with their pros and cons. True, the authors keep referring to other texts that seem to be all about branching, but they still should get credit for linking branches to waste, or at least having found a text that does. Think about this again: Branch equals unintegrated code. Unintegrated code equals waste.

ITIL seldom coexists with "agile" in a book. This is the first time I've seen it in one, and I think it's a very good thing that the authors acknowledge that some organizations will be running ITIL, and try to make the best out of it and explain how the material is related that that framework.

In the same chapter, a maturity model is presented. It resembles CMMI, but if I understand correctly, it's been developed by the authors and their colleagues to illustrate maturity in six fields on a scale from -1 to 3. The fields are: build management and continuous integration, environments and deployment, release management and compliance, testing, data management configuration management. Such a model makes an invaluable tool for everybody who has set out to implement continuous delivery in an organization. I'll enlarge it and print it.

That should cover it! Apart from some vagueness, this is a very good book, and I really enjoyed reading it. You could say that it's like a thermometer and an index. The thermometer shows what the industry is up to, or at least what it should be up to, and the index points you to software and further references. It took some time to read, but it was a pleasure. For those who have done nothing in order to approach continuous delivery, I'd suggest to first take a look at continuous integration before trying to swallow this book.

Who should read this book

Continuous delivery will become a standard practice in a couple of years. Picking up an introduction like this is clever thing to do.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.