Coding Horror has a post titled, “The F5 Key Is Not a Build Process.” It references a series of emails chronicled by HackNot as a new employee gets up to speed on a company’s build “process.”
Anyone who has been a developer for a while has seen aspects of this scenario play out. I can say from experience that having an automated build process makes all the difference. Here are some of the keys to creating a good build process.
Build Musts
<li>Dedicated Build Environment - You need a dedicated server to run your build process. Under no circumstances should this be a developer's workstation. The dedicated build environment could be anything from a virtual machine to a build lab full of compilation & testing servers, but it must be dedicated to the purpose. If possible, this build environment should run your unit tests and functional tests as well. In several teams that I've been involved with, we've even kicked off the install program and started automated integration testing for each build.</li>
<li>Ship From the Build Environment - Builds that you ship to a customer must originate from the build environment. In fact, your build server should generate your install package. This means that you can produce an installable build (at least theoretically) at a moment's notice. It also means fewer mistakes when shipping to a customer and the result will be predictable.</li>
<li>Regular Builds - Your build process must kick off at predictable intervals. For large projects, having the process start once or twice a day works well (overnight for example). If possible, you should try continuous integration. With any of the CruiseControl variants you can set up your build to automatically kick off every time code is added to your repository.</li>
Build Niceties
<li>Predictable Output Versioning - It helps a lot if the output (installer, compiled dll's, etc...) have version numbers that are unique to each build (via an automatically incrementing counter). This way, there can be no confusion about two builds with the same version number but different functionality. On one project we even had the least significant part of the version number encode the date and time of the build. So, we could take a dll from a test machine or customer machine and know what date and time it was compiled. Since compilation always comes from the source repository and there is only one build environment, we could tell exactly what code made it into that build.</li>
<li>Monotonically Increasing Build Numbers - It helps if the build numbers always increase over time. Sorting by version number will then result in chronological sorting of builds as well.</li>
<li>Automated Integration Testing - With virtual machines and the power of automation tools today, you can set up a build environment that automatically installs your software on a fresh machine, and starts automated integration test scripts, reporting the results back to the development team. While this can be difficult to set up, it's worth it over the long term.</li>
It’s much easier to start a continuous build environment like this when the project is small. Once it gets large, you may never be able to get the time to put together the build infrastructure. Taking some time up front to do it right will pay dividends when you get down to shipping deadlines. Your build server could end up being your best employee.