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.