October 26, 2004

Dear Manager,

When I talk with the developers on your team, they tell me they need a dedicated build machine. I'm partly to blame. See, I've been showing them a free build scheduler that, after just a few minutes of configuration, will continuously build your software with no human intervention. That's good for them, and it's even better for you. Let me tell you why.

• If you build and test your software once an hour, no problem is more than an hour old.
• This makes it easier to find and fix problems, which saves time and money, and lets your team concentrate on adding new stuff, not fixing old stuff.
• The continuous build process feeds you valuable and timely information, letting you manage the development more tightly.

Here's how it works: Every hour, for example, and only if new work has done, the build scheduler checks out a fresh copy of your project from version control and attempts to build the project. The build process includes compiling all of your project's source files, running an arbitrary number of tests, and generating any other build artifacts, such as project metrics. If, for any reason, the build process is unsuccessful, then the build scheduler can notify you via email, your cell phone, RSS, or a visual device such as a lava lamp. You can also use your web browser to view the current status of the build, or any prior build.

Running builds throughout the day whenever changes are made to the project is a tireless job, which is exactly why you don't want your developers doing it. They would rather focus their time and energy on writing quality code that ultimately helps you deliver valuable software to your customers. But building the software on a frequent interval is also an important job because finding and fixing integration problems right before a release---when you have the lowest tolerance for risk---can be costly. With the build scheduler constantly integrating your software, problems are detected almost as soon as they're introduced, giving your team the maximum amount of time to fix those problems before they start to compound. In turn, you receive the benefit of knowing the health of the software all day, every day.

Your developers already understand the value of continuous builds. They know getting constant feedback about the build will help them stay on track. They know staying on track is equally important to you. And they're happy to invest a few minutes setting up a build scheduler that continues to pay back precious dividends: time and money. There's just one minor problem. Thankfully, it's one of those unique problems that can be quickly solved with a one-time expenditure. That's where you can help by approving that expenditure. Simply put, your project can't afford not to have a dedicated build machine.

Now, you might be thinking that with all the machines on developers' desks you already have plenty of horsepower for continuous builds. But it's not about horsepower; it's about availability and independence. Running continuous builds on a development machine will slow down the developer who owns that machine. The money you save by not purchasing a dedicated build machine will quickly be overrun by paying a developer to work slower. Additionally, a dedicated build machine is independent in the sense that it hasn't been biased toward any particular developer. It takes what's in version control to be all that's necessary to create a build. If the build succeeds on the dedicated build machine, it means that anyone on the project can create a build given access to your version control system. You get the peace of mind of knowing that everything that goes into the release is safely tucked away in a centralized repository.

Finally, please allow me to summarize by presenting the economics that I continue to see ignored by your competitors. Consider that on average your ten-person development team costs, conservatively, $500 per hour. (It's probably more like $1000 per hour when you consider all the care and feeding expenses.) If your team spends a total of two hours over the life of the project debugging integration problems (start counting whenever you hear a developer cry "But it works on my machine!"), then you've already paid for a respectable build machine. Then when you consider that those debugging sessions are delaying your product going to market, you really can't afford not to have a dedicated build machine.

I hope this helps clarify what you may have heard about continuous integration. If you have any questions or concerns, let me know.

Respectfully,
Mike

About the author