Build Early and Often

Is the continuous build model right for your shop?

• By Peter Varhol
• March 1, 2008

The two or three developers who build the software are looked upon with a combination of admiration and fear -- admiration because they have the mental capacity and organizational ability to keep it all straight, and fear because there has to be something just a little bit, well, different about someone who can do that.

It doesn’t have to be like that. You don’t have to keep making sacrifices to the gods of dependencies as a part of your build strategy. Instead, you can build early and often. Start building as early as possible in the dev cycle, when you have all or most of your files in place, and keep on building on a regular basis until you ship the software. Building regularly makes you confident that you can do so when it comes time to deliver the application. If you get into this habit, the last few builds won’t be so stressful.

The latest trend is continuous build. It’s what the name implies. On every check-in, you kick off a new build. Not a local build, which you’ve presumably already done, but a product build. You may object that a full build can take a couple of hours, but, in fact, intelligent build technology will build only those files that have been changed. Depending on the extent of the check-in, a build might take only a few minutes.

There are a couple advantages. First, you know you can build because you do it all the time. There won’t be any last-minute fire drills because the application won’t build when it’s due to ship. Second, your testers get to see the results of your work almost immediately. If there’s a problem, the code is still fresh in your mind.

Building continuously, or even nightly, probably isn’t going to get you to the finish line faster. You still have the same amount of work to do; you’re just doing it earlier and a little more rigorously. You might actually be losing any productivity gains by spending more time investigating and fixing build breaks.

It’s probably not going to mean a product with fewer bugs. Granted, frequent, regular builds help you find bugs sooner, and fixing some of these early might save you bigger headaches later. But the process won’t completely stop bugs from making it into the code base.

What continuous build does is make the development process more predictable. If you know that you can build the software, then there’s never any doubt about your final steps in the process. Building frequently takes the uncertainty and guesswork out of actually putting your software together. Writing code might take longer than estimated, or requirements might change, resulting in changes to the development schedule, but if you know you can always build, that takes some of the uncertainty out of your process.

Continuous or at least frequent builds are an important component of agile development methodologies. If you’re going to deliver a new version of the software every two or four weeks, it’s best if you have built the software a few times during that interval.

Is it worth the effort to change your processes to build nightly or continuously? That part is up to you. But if you’re only building at major milestones today, that’s probably not enough. And if your build process breaks more often than it works, you’re probably spending too much time fixing broken builds, and not enough time building. Finally, if you have difficulty getting to the end of a project, and the delay is costing your company money, nightly or continuous builds are a must. I guarantee it works better than black magic.