Lots of people have a common misunderstanding of the (subtle) differences between the various tooling regarding continuous integration and build automateion. Here’s the gist of it:

Build automation:

Build automation tools are tools you use to automate the build process, instead of doing it manually. Build automation tools include:

• batch files
• MSBuild files (csproj and vbproj files are really msbuild files inside, for example)
• NAnt files
• FinalBuilder (slick, visual editor, hundreds of built in tasks)
• VisualBuild (slick, visual editor)
• Rake (based on Ruby)
• BooBS (Boo Build System)

 

Continuous Integration:

CI tools are the triggers that listen to various “events’ in the network (a check-in to source control, for example could be a trigger. You can configure these tools to do a few simple things when an event happens. One of those things can be to invoke one of the tools in the previous list. Some of the CI tools, though, include a few simple built in build atomation power (such as built in MSBuild support, or running tests) but you would do much better choosing a CI tool that invokes a build automation power tool, since each are design with different goals in mind.

CI tools include:

• TeamCity (recommended 0 invokes msbuild, command line, tests, and more)
• Team System Build server (invokes MSBuild files)
• Hudson (mosty used in Java contexts but I hear some .net devs use it too)
• CruiseControl.NET (xml based – very mature but also old fashioned..)
• others..?

What should you use?

I really like to take the best of each category. I’ve found the combination of using TeamCity to listen and configure events which then triggers a FinalBuilder script file as an ultimate combination of both power and (very important!) maintainability and understandability of the process.

I really despise tools that force you to configure huge xml files (msBuild, CCNet, NAnt) as that is a maintainability nightmare waiting to happen.