The Build Server: Your Project's Heart Monitor

If you really want to get fancy use a new VM instance to build on everynight, sort of a way to ensure everything is absolutly clean everytime.

Anyone such as our host who feels that a build server is not necessary is not working with a sufficiently complex project. Although I feel even a single application project benefits from the use of a build server, once you gain complexity (eg 4 interdependant COM dlls, 12 support applications, 4 type libraries … you get the point), a build server becomes an absolute necessity. It is the only way that you can be sure of two things.

A. You have not broken any application or dll with a change you made. Since you may not build all binaries affected by a change on your machine.

B. You have built exactly what you want. Often a release or test build will have different options and Compiler directives than one built on a developer machine. A build server ensures you always build with the correct options.

We us finalbuilder at my company, which I can heartily recommend.

http://www.finalbuilder.com

I highly recommend virutalizing your Build Server.
I run my Build Server in a VM and uses a combination of CruiseControl.NET, nAnt, and vbscript. This allows me to restore the build server to a clean state if something terribly goes run (such as the test install screws up the registry) and also allows me to use the host computer for other tasks.