In a nutshell, the build process gathers up the collective works of all your developers and assemblies it into a deployable package. A good build process should acquire the latest version of source code from the source code repository, update the version number, execute a complete build of the source code, run code analysis tools, execute unit tests and drop the resulting deployment package in a known location. A process like this will provide your development team with high level of confidence as to the quality of source code they are producing.

A build process must be automated. Automation will ensure each build is consistent and can be reproduced. Automation will also enable developers to focus on the task at hand, creating the application. For example, I was involved in a project where they had a manual build process. When I first arrived on site it would take, on average a full day to complete a single build of the application, involving the time of at least 3 developers. After automating the process the build would take a total of 20 minutes and the involvement of no developers as the build was scheduled to execute every night automatically.

I would highly recommend dedicating a developer to the creation and maintenance of the build process, the Build Master. You will need someone to create the process in the first place and make sure that if the build fails, the cause is discovered and corrected immediately. You build is a measure of the health of your project. A failed build signifies that you are not able to deploy a new version of the application. There is no point adding more functionality if you do not know if what you have already created works. You could be adding on top of a flawed base. Also a failed build could cause your entire team to be unable to compile their application because syntactically incorrect code was checked in or a change to one class causes another class to break.

Once all of this is in place a team will need to decide how often to execute a build. There are many thoughts around this but I would recommend that you run a full build no less that once a day. The more often you execute your build the higher you confidence in the source will be. Some shops will schedule a build to execute during the day or night, others will employ continuous integration.

Continuous Integration is a process that monitors your source code repository for change. When a change to the source code is detected (a check-in), a build will be executed. This ensures that if source code is checked-in that is flawed and fails the build process the build master will be notified as soon as it happens. This makes tracking down and correcting the flaw much simpler. Obviously, the longer you wait to execute a build the more difficult it will be to track down the flaw amongst all the changes.

There are some great tools available to assist you in creating and monitoring your build process.

Some of these tools are:

Build Scripting Tools
· MSBuild
· NAnt

Build Monitoring Tools
· Microsoft Team Foundation Server
· CruiseControl.NET