Book Review: Continuous Delivery

Book: Continuous Delivery

Authors: Jez Humble and David Farley.

Addison Wesley, 2011

I had two simultaneous impressions when I browsed Continuous Delivery. The first impression was “is there anything really new here?” and the second was “humm… I have actually never seen a book that puts together all these topics that do have an important relationship.” Throughout my career I encountered over and over the continuous struggle between diverse teams to successfully develop and deliver software. Communication, coordination, and collaboration have always been an often-ignored important factor that affects the effectiveness of organizations. Add to that the lack of a coherent infrastructure to make design, development, testing, integration, and deployment fit seamlessly and the end result is the nightmares way too many organizations deal with on a daily basis. I decided to read on because I appreciate the importance and complexity of those issues, years ago when I built QA organizations for diverse companies, and the last couple of years coaching and consulting enterprises in the adoption of Lean-Agile practices and the importance of Value Innovation.

Jez and David did a very good job at addressing the infrastructure coherence issues and propose effective ways to bring order. The novel aspect is not the fact that, say, good configuration management, continuous integration, and testing are very important to the increase of software quality, and to both managers and engineers mental health. The value is in the way to make this happen successfully and with minimal effort. They rightfully use the term Delivery Ecosystem and put together innovative thinking with strong bases on the importance to optimize the entire process, increasing quality, reducing technical debt and, best of all, making work life easier to technical stakeholders. The single automated pipeline approach is in agreement with current practices influenced by Lean and Agile.

Part 1 is a very god compendium of practices necessary to every software development organization, which the authors present as the challenges to deliver software. Jezz and David begin by presenting some release antipatterns and what to do about them. Then they address configuration management and continuous integration, where they describe diverse types and practices, pointing out essential characteristics and making suggestions to make them more effective. The last chapter of this part points out the importance of testing and explains it in terms of the test quadrants as proposed by Brian Marick and mention some real life situations.

Part 2 focuses on the deployment pipeline. Jez and David begin with its components—or anatomy—from practices to its stages. They did they right thing by including automated and manual test strategies. The following chapter focuses on scripting for build and deployment by first mentioning some build tools and then guiding the reader by the hand on the basics to get builds and deployments automated; and is complemented by a short chapter on the commit stage wraps it up. The next two chapters focus on testing, automated acceptance and nonfunctional requirements. These topics are not comprehensive due to the extent and complexity of the topics but the authors made a good job at bringing the key factors to motivate the reader to understand their importance and to explore further. This part is concluded with a chapter on deployment; an activity taken way to lightly most of the times and a main point of failure for most organizations. The authors cover zero-downtime releases, emergency fixes, and other.

The last part of the book is on the delivery ecosystem. This is the most important part of the book. I would say that very senior leaders and very senior technical staff with rich, broad and in-depth experience may be able to browse through Parts 1 and 2, but should slow down and read in more detail this part. This is the glue that puts things together.

Concluding. This is a vey good boo that should’ve been written many years ago to avoid so much waste and pain by so many technical organizations because it puts diverse parts of the software development organization puzzle together in a way they actually fit together. The only aspect I wish was also there, but isn’t, is the human factor. That is, how to get not only the complexity of processes and infrastructure to work together coherently, but also how to get the people behind the process and infrastructure to also work together coherently. In any case, that wasn’t an objective of this book.