|Paul Duvall, author, Continuous Integration: Improving Software Quality and Reducing Risk|
To paraphrase Martin Fowler, continuous integration is the practice where team members frequently integrate their work with the rest of the development team. Integrations occur soon after changes are committed to a version control repository. I recommend that developers (or pairs) commit their changes at least once a day. This means that a development team will have many integrations per day -- ideally, on a separate integration build machine.
When used effectively, CI provides benefits like rapid feedback on the "health" of the software under development. It identifies defects early in the development cycle. It enables project visibility at all levels. Also, defects are often smaller, less complex and easier to fix; the team has increased confidence to make changes; and working software is always available.
The concept has evolved over the years, from the daily build to building with every significant change. The difference is considerable because in order to be successful at CI, it takes the entire development team to follow common practices. CI was originally associated with Extreme Programming, but can developers using more conventional development methodologies also employ CI?
Sure, CI works well in iterative environments such as Agile and RUP (Rational Unified Process), but CI can provide similar benefits on waterfall projects during the construction phase. In fact, on some government projects I've worked on, I've used many Agile practices internally, including CI, while adhering to the waterfall cycle imposed on our team. If you're creative, CI can add value using any "methodology." Can you briefly describe your book, Continuous Integration: Improving Software Quality and Reducing Risk?
Using examples, the book describes how to effectively use CI to reduce risks on software projects. We cover over 40 practices, including 70 code listings in languages/environments such as Java, Ant, NAnt, JUnit, NUnit, Ruby and so on. The target audience is development teams. The first part of the book addresses the fundamental practices of CI and the second part describes how to create a full-featured CI system including database integration, testing, inspection, deployment and feedback. We finish by giving the reader resources, evaluations and approaches in best determining the proper CI tools for the job.
It's my fundamental belief that we will never find a "silver bullet" solution to software development, and this is why I like the principle of CI. It assumes that software will break. But, when used effectively, you find out about the breakage in smaller chunks and more frequently, when it's easier to fix.
In terms of software quality, CI can help you measure cyclomatic complexity, code duplication, dependencies and coding standards so that developers can proactively refactor code before a defect is introduced. If a defect is introduced into a code base, CI can provide feedback soon after, when defects are less complex and less expensive to fix. Also, when using an effective developer testing regimen, CI provides quick feedback, via regression tests, on software that was previously working and is adversely affected by a new change. How about ROI?
Calculate how much time your team spends on fixing defects once the software is with the testing team -- QA, integration testing, etc. Of course, it costs considerably more once it enters production. When implementing effective CI practices, you can discover many of these defects as soon as they are introduced, which significantly decreases the cost of fixing each defect. What are some tips the book offers on how to make integration a "nonevent"?
I introduce a recurring theme that I refer to as the "Integrate Button." Early in my career, I saw an advertisement in a large IT trade magazine with a picture of single keyboard button, much like your Enter key. At the bottom of the ad it said, "If only it were this easy." To me, it meant making software integration a "nonevent": a single press of the button to integrate. In the book, this relates to the "Automate Builds," "Perform Single Command Builds" and "Centralize Software Assets" practices.
With these practices, you completely script your build so that it can be run by a headless process such as a CI server and that it doesn't rely on an IDE or similar dependency. You "centralize software assets" by putting everything you'll need to build your software in the version control repository. Finally, you make certain you can "perform single command builds" without needing to configure this file or that variable, ensuring a smooth integration build.
Something I've found amusing is that some teams will blame CI for their problems. They'll say, "Before CI, we never had these types of problems." They were referring to broken builds, including tests and so on. I almost want to laugh out loud or scream -- I'm not sure which. CI acts as a mirror of your software under development. In fact, you should thank CI for letting you know earlier in the development cycle. The irony is that bigger, more complex systems that are more difficult to integrate, should be integrated more often.
We recommend that developers commit all of their changes to the repository at least once a day. Depending on your team, this may necessitate a change in behavior, particularly breaking up tasks into smaller chunks so that they can be committed often. This will lead to many integrations per day. Depending on the team, it can be disruptive, but so can discovering defects late. CI is largely a change in a development team's behavior along with correct implementation of tools. Given that, you may need to start teams with a daily build and incrementally move toward CI as they learn new behaviors. Can you describe some of the practices your book includes on how to use CI effectively?
Most of the chapter subheadings are identified as practices, such as "Commit Code Frequently," "Categorize Developer Tests," "Use a Dedicated Integration Build Machine" and "Use Continuous Feedback Mechanisms." For instance, in "Categorize Developer Tests," we describe how and why you can separate tests into distinct "buckets" such as unit, component, system and functional. To do this, you can use annotations with frameworks like NUnit or JUnit(4), file/directory naming or other options. The benefit is that you can run faster-running tests first, followed by longer-running tests which improve build execution time, which can be the bane of CI. This practice works well with another practice we recommend which is "Stage Your Builds," so that the development team gets quicker feedback on the integration build status. How about some tips on choosing an appropriate CI tool for your project?
We describe five primary factors in choosing an appropriate CI tool, not just servers but build tools as well. These are functionality, compatibility with your environment, reliability, longevity and usability. As with most things, you can't just throw a tool at the problem. That said, tool choice can be an important consideration in the CI toolbox. The book covers CruiseControl, Ant, Rake, Luntbuild, Maven, CruiseControl.NET, AntHill, Continuum and other tools. As an industry, where are developers on the adoption curve of CI?
We are getting there in a technical capacity, using automated build tools, CI servers and so on. However, we are still a ways from realizing this as a common practice, which is why I wrote the book and why we work every day at Stelligent to make this a reality with software teams.
In the book, I state that according to a worldwide study, approximately 27% of development teams perform a daily build. Given this, less than 27% teams are doing CI. And less are implementing comprehensive automated developer tests and inspections as part of their CI builds. There's a lot more for us to do as an industry. I've found few that can look at me with a straight face and tell me that CI would not be beneficial to their project. Whether or not they implement is, often, another matter. What do you hope the takeaway is from your book?
I hope readers walk away from the book thinking, "Yeah, I can do this; I can setup a CI system along with processes and practices with my development team." Furthermore, they'll know why and how to use certain CI practices. They'll also realize that they don't need to do everything at once to be successful.
I also hope readers realize that a build is much more than compilation. A build can include database integration, automated tests, inspections and deployment with every change applied to their version control system. Readers should also know that Integratebutton.com contains all of the examples from the book and all the scripts for creating a full-featured CI system along with examples in other languages that are not included in the text.
Paul Duvall is CTO of Stelligent Inc., a consultancy on optimizing software production, and co-author of the new book, Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, June 2007). He is a featured speaker at many leading software conferences and has worked in virtually every role on a software project. Duvall contributed to the UML 2 Toolkit (Wiley, 2003), authors a series for IBM developerWorks called "Automation for the people" and authored a chapter in the No Fluff Just Stuff Anthology: The 2007 Edition (Pragmatic Programmers, April 2007. Prior to Stelligent, Duvall was CTO of Pyramid Systems.