CruiseControl [.Net] vs TeamCity for continuous integration?

I have worked on and with Continuous Integration tools since the one that spawned Cruise Control (java version). I’ve tried almost all of them at some point. I’ve never been happier than I am with TeamCity. It is very simple to set up and still provides a great deal of power. The build statistics page that shows build times, unit test count, pass rate etc. is very nice. TeamCity’s project home page is also very valuable.
For simple .NET projects you can just tell TeamCity where the solution is and what assemblies have tests and that is all it needs (other than source control location). We have also used some complicated MSBuild scripts with it and done build chaining.
I have also gone through two TeamCity upgrades and they were painless.

CruiseControl.NET also works well. It is trickier to set up but it has a longer history so it is easy to find solutions on the web. Since CruiseControl.NET is open source you also have the option of adding or changing whatever you like. I had used CruiseControl.NET since its release and wrote some of the early code for cc.tray (thankfully re-written by someone who knew better).

Cruise, from ThoughtWorks, also looks quite good but I don’t see a compelling reason for me to switch. If I were starting a new project I might give it a try, but TeamCity has done a great job of making the simple things simple while making the complex quite painless.

Edit:
We just upgraded to TeamCity 5.0 a few weeks ago and it was another painless upgrade. It let us take advantage of the improved code coverage capabilities and GIT support. We are also now using the personal build and pre-tested commit features that have been in for a while. I just thought I should update the answer to indicate that TeamCity keeps improving and is still easy to use.

Leave a Comment