I finally picked up a copy of “Continuous Delivery” (http://amzn.to/9NNsd8), the latest in the Martin Fowler Signature Series from Addison-Wesley. I have been really looking forward to this book ever since seeing the table of contents and some early drafts online.
Full disclosure here: I’m only about a quarter of the way through it as of now.
I went into reading this book with high expectations – anyone who is interested enough in continuous delivery to write a book about it simply must be extremely passionate about it. They had met my expectations when on page 5, I read this sentence: There should be two tasks for a human being to perform to deploy software into a development, test, or production environment: to pick the version and environment and to press the “deploy” button. This sentence perfectly sums up my philosophy exactly around deploying software. This is a critical piece of the puzzle with projects that leverage agile philosophies such as “deliver early and often”. If you are going to be deploying often, you had better get it down to a science, and it had better be simple, fool-proof, and fully automated. I firmly believe this is a “must-have” for our custom development projects, and the larger the project the more critical this concept is to the success of the project. I’ve seen larger projects spend significant (20%+) amounts of their total effort in just attempting to manually configure and deploy software to multiple environments over and over during the project lifecycle.
My impression thus far is that the authors are very knowledgeable about continuous delivery as a topic, and have a pragmatic take on it. I also appreciate their analysis of how DVCS (distributed version control systems) play into the practice of Continuous Integration. This has been something I’ve struggled with in terms of seeing the value of a DVCS – if you have branches everywhere, and no real mainline trunk, how can you really do CI? I appreciate their analysis and recommendations, and I look forward to Chapter 14, on “Advanced Version Control”.
I believe that anyone who has gone or will go through the process of releasing custom software inside an enterprise, especially a large enterprise, could get some real value out of this book. Their philosophy and practices are well thought-out, and clearly based on real-world experiences. Not just code developers either – there are chapters on data and infrastructure delivery and management as well that I haven’t yet gotten to, but appear to have valuable patterns that can be used by people responsible for these aspects of software delivery.
To summarize, even though I’m only about a quarter of the way through it, this is looking like a very good read, and I look forward to the future chapters. I’ll post a final review once I’m all done.