Comparison between CruiseControl, TeamCity and Team Foundation Server

Question

Today we are using TFS 2008 for source control, and I imagine we will go for TFS 2010 as quick it goes RTM.

We are going to use some continues integration tool but which one? I have been looking at both TeamCity and CruiseControl.NET both seems quite good (TeamCity were a little more easy to configure). I have seen some really promising screencast about TFS 2010 automation tools and it looks really good. But I have only scratched the surface of the tools.

Which one should I use?

Answer 1

We started with CruiseControl.NET and NAnt. These are free tools and give you total control. They do integrate with TFS source control through a plug-in. The disadvantages were learning curve, poor documentation (for CC.NET), and XML editing. It came down to one developer (me) maintaining the scripts.

We finally switched to TeamCity. It integrates with TFS source control; most standard actions can be done out of the box. It's easy to use (web-based), so any developer can set up his or her project in it with minimal training. For advanced usages, it integrates with NAnt. You will want a fairly hefty server for the build machine (although agents can be distributed).

I haven't tried the TFS CI features; TeamCity does what we need it to do. There's a free version for starters; if you outgrow that, a license is reasonably priced for a mid-size development shop.

Answer 2

Given that you're already using TFS, I'd try TFS' CI tools first and reconsider your decision in the event that it doesn't meet your needs. In fact, TFS 2008 has CI features: I'd set them up sooner rather than waiting until 2010 to drop.

My team is using some of TFS 2008's CI features now and they've been working reasonably well for us. Setting up the builds themselves was not difficult and the integration with TFS's work items is quite solid (work items are created in the event of build failure out of the box).

I will admit our system is fairly simplistic: we have not yet put the leg work in for assembly versioning (since it looked like a great deal of leg work) and we're not unit testing either (unfortunately). It seems MSTest unit testing would just drop right in though!