Summary Getting a good continuous integration process in place poses many challenges. One of the biggest is making sure you have the discipline to support it.

Preaching to the choir

I recently attended a talk by Eric Pugh of Open Source Connections on the fundamentals of continuous integration, or CI for short. I'm certainly no stranger to CI practices, so this was a case of preaching to the choir for me, although it's obviously nice to hear things that you already believe validated by others who are respected in the field.

On the surface, it might not seem very useful to go to a talk where you already agree with most of what the speaker's going to say, but in fact, there's a good amount of value. In particular, it's always enlightening to see things from the perspective of a newcomer, and to see how they respond to these ideas. Their tabula rasa can sometimes lead them to ask insightful questions that you wouldn't otherwise expect. Having a blank slate without any preconceptions of how things are supposed to work is often a significant advantage.

As Eric zipped through his slides with practiced ease, I couldn't help watching some of the facial reactions of the attendees. It was easy to tell who was fast becoming a convert (or, like me, was already drinking the Kool-Aid) and who was still skeptical. Although it was clear that most people wanted to go back to their respective projects and start exploring this right away, I got the sense that some had some lingering questions about exactly how to do just that.

And that's a very real problem.

So what's so hard about CI?

Initially, it may not seem like CI should be hard, and that its benefits should tend to outweigh its costs anyway. But the road to getting there can be a little bumpier than its more zealous advocates are willing to concede. Like many agile ideas that have people at their core, continuous integration is as much a discipline as it is a practice.

• By practice, I mean the specific implementation of an idea on an organization or project.
• By discipline, I mean the change in individual thinking and activity that is required to get the most out of the practice.

For example, the continuous integration practice is often accomplished by having a CI build server and active, automated builds that run on it. Most organizations that have this will feel comfortable telling you that they're doing CI.

Certainly, securing the appropriate technology resources for CI practices is hard enough. You'll not only need a box that's robust in both its CPU and memory limits, but also the technology staff necessary to configure and maintain any environments you care to build against. These are nontrivial financial, technology, and human capital commitments.

But how useful is the practice if people don't change their behavior to incorporate it? If build status reports are simply ignored, or if no one considers a broken build to be a priority item for their attention, are you really getting the most bang for your buck? Are you getting any? If effectiveness hasn't improved, you're not much better than where you were before, and you just invested a lot of effort to go nowhere.

Practice is the easy part; discipline is the challenge

Thus, the continuous integration discipline is the tricky piece, and this is the often-overlooked segment of many agile techniques. It is achieving the discipline that is the real challenge to the adoption of a continuous integration practice. How difficult the discipline is to master depends on many factors, including but not limited to:

• Organizational/project support for the practice. Are the agilists (or anyone introducing new ideas) seen as renegade vigilantes sabotaging the existing development process? Or is their experimentation welcomed as potentially valuable innovation? Too much resistance from management can be fatal to the health of an idea. (Some skepticism is always healthy, of course; new technologies shouldn't be arbitrarily and permanently adopted without careful consideration.)

• Buy-in from team members. How receptive is the team to new ideas? Do they take active steps to give new practices a fair shake, or is the deck stacked in favor of the status quo? Part of the effectiveness of any practice stems from how its users derive value from it. If developers and other team members are not persuaded of the ultimate value of a practice, they are less likely to be tolerant of its faults when things occasionally go wrong.

• Team culture. Does the team value technologies that can help improve their productivity and help deliver a better product? Do they acknowledge pain points and take steps to remove them? Without these things, it's going to be hard for new ideas to gain a foothold.

What discipline is needed?

Fortunately, adopting CI itself doesn't require too much of a change in the way non-CI teams do their work. Typically, three kinds of activities help maximize the effectiveness of CI practices:

• Incremental changes. CI works best when changes can be viewed as a stream of small updates, rather than punctuated explosions of new source code. Each time a change is made, it will be obvious that any resulting problems are probably confined to that spot. Chunky changes, by contrast, reduce the effectiveness of CI, because when the build breaks it may no longer evident where to start looking. Each part of a monolithic commit must be viewed as potentially suspect.

• Instant feedback. People learn and improve best when their actions are closely tied to the feedback from those actions. The farther removed the feedback, the less relevant it becomes. Therefore, you want the feedback from a continuous integration process to come through as quickly as possible. Without timely feedback from builds, your team members will get less value from CI.

• High build confidence. It should be possible to rely on the CI process as a trusted ally and quality tool. If this confidence is shaken through too many (or even just a few) false alarms, it may take a while to regain that trust. Developers do not need to add the cognitive load of trying to decide whether a build failure is legitimate or not to their plate.

CI is ultimately about people, not technology

Together, these factors combine to produce an insight that might only be obvious in retrospect: Agile technologies like CI depend first and foremost on the people whose efforts they support.

Inevitably, people are the ones making the judgment calls in a CI system, not technologies. It is always a human who must decide how to proceed when a decision is required. You can spend a significant chunk of cash on new and shiny boxes, and you may well see improvements from doing so. But you'll stretch any investment much farther if you make sure that you have the discipline necessary to understand the practice first.