Continuous Integration: Improving Software Quality and Reducing Risk
Paul M. Duvall
Addison Wesley, 2007
336 pps, $44.99
ISBN-13: 978-0-321-33638-5
Since I wrote "Automated unit tests are an essential part of today's mature development environment" in my review of xUnit Test Patterns, I've evolved my thinking to add the "but they are worse than useless if not run. Often." I've been peripherally aware of Continuous Integration (CI) before reading Paul M. Duvall's new book on the subject, appropriately titled Continuous Integration, but am now a full-fledged convert. In fact, this book has the potential to become the one that unifies a large number of other books on my shelf.
Like a lot of books recently, Continuous Integration is divided into two parts -- one theoretical, the other practical.
The theoretical section is an overview of the concepts and practices that make up a CI system right from what a build is (a set of activities performed to generate, test, inspect and deploy software) up to common policies that are employed at the same time as CI. If you are trying to get managerial buy-in to the idea of CI, then this section is for you, especially the chapter on Reducing Risks Using CI. In this chapter, four common risks (lack of deployable software, late discovery of defects, lack of project visibility and low-quality software) that CI can address are used in brief case studies which the reader can adapt to their environment. This section ends off with techniques and practices around your build which are valuable to any build system, not just one that will be ending up as part of a CI infrastructure. Since finishing his book I've been trying to implement such things as Fast Building, Fast Failing builds which are Separate from IDE; all ideas I had sitting half completed in my head but were crystallized by this section of the book.
The practical section is aimed at whoever is tasked with creating and maintaining both the CI server and build that it is executing. If that is not you, then it will be of less value than the first one, but it is still useful to know what the CI system can do so you can request it from the appropriate person or team. As a tester I was most impressed that three of the five chapters are directly related to testing. It is through automatic seeding of the database (Chapter 5), executing dynamic xunit tests (Chapter 6) or static analysis and inspection (Chapter 7) at every code change that really makes CI shine. This section wraps up discussing ways to notify stakeholders of build results and how you can use CI to deploy your application all the way into production with a single push of a button.
One thing that started to annoy me by about halfway through is the over use of certain source material. Yes, this book is part of the excellent Martin Fowler Signature Series, but he is mentioned either directly or via reference to his CI article enough that it becomes noticeable.
Something I have been paying attention to recently is whether the physical book is appropriate for the content and Continuous Integration certainly is. The font is larger than some technical books, there is plenty of space between lines and the figures and sidebars are clear and nicely describe the related contents. I was also thankful for the 15 blank pages at the end for notes. Not only is the main section of my copy well highlighted but a couple of the pages of filled up too.
As part of my day-to-day QA responsibilities, I have been getting more and more interested in how we as a complete team can improve the quality of our application earlier in the cycle where bugs are the cheapest to find and fix. In talking to test leads at other organizations, they too are looking to solve this problem. While Continuous Integration does not go into the nitty gritty of how to do things like configuring Ant or tuning false positives from static analysis reports, it does give you the complete CI picture which will put you in the right mental state to convince others that they are worthy of precious time in the schedule and a solid base to begin implementation.
While build processes are traditionally the domain of the development group, I have already recommended Continuous Integration to a number of people, both tester and developer. As code becomes more complex and the need for more sophisticated and automated testing increased, I suspect I will recommend it some more.
