Making the Build

I am of the belief that an automated build process is perhaps the most essential element in producing a quality software application. The build process can be used to enforce good practices within the development team and also detect any issues within the application in a timely manner (the sooner you know about a problem, the less code you have to look at to determine what caused it). Even a small team with a simple application can benefit from an automated build process.

Recently I've gotten the opportunity to recreate the build process for the company I work for. The product is over 5 years old, is fairly large and complex (well over 200 separate .Net projects as well as database and legacy code), and has grown a fairly complicated build process using a combination of batch files and custom executables.

The main reason for recreating the build process is due to the difficulty of maintaining it. There were quite a few batch files and it wasn't easy to run. We averaged a build about once a week (builds should be run several times a day, nightly at most) and the unit tests weren't run very often and if they were, the results often times weren't published (it could be months before you find out a unit test no longer works and then who knows what changed that broke it).

I started building my own build software using Windows Workflow (see my April 28th post, Windows Workflow and Your Next Build System). Although it probably could work and is a great way to learn Windows Workflow, I soon remembered one of my life rules, always use the right tool for the job.

I decided to try FinalBuilder instead and boy am I glad I did. FinalBuilder (FB from here on) is a great build tool. They have dozens (maybe hundreds) of different actions (that's what they call activities or tasks) available to use, such as MSBuild, get from VSS, run SQL, update AssemblyInfo, NUnit, send email, etc. They also allow you to write script (either VBScript or JavaScript) that is run during the build. If that isn't enough for you, you can also create your own custom actions using .Net (or other supported languages).

I've looked at several of the build tools available out there today (especially the free ones :) such as MSBuild and NAnt and the thing that strikes me about these tools is that they seem to be designed for full time build engineers. I don't have time to figure out how to setup these tools let alone write a complete build process using them. Perhaps even more frustrating is that I actually did take the time to learn MSBuild at one point and had done some interesting things with it, however, I couldn't tell you the first thing about MSBuild anymore. I wouldn't use MSBuild to create an entire build process for the same reason I wouldn't use Perl to write an entire ERP system (write only code doesn't work well in a complex, constantly evolving product).

I am not sure if it would have taken longer to create the build process using another technology (such as MSBuild or batch files) or not, but the big benefit in using FB is in the ability to maintain it months later and, if I'm lucky, by somebody other than myself (I definitely don't want to be the "build" guy).

I'm sure there are other great build tools out there. If you know of one, feel free to leave a comment (I always love to find out about new tools :). I plan on writing another article within the next week or two that has more concrete tips for creating a build process (perhaps even some source code), so stay tuned.