Cruise Control .Net vs Team Foundation Build [closed]

Question

Our team is setting up nightly and continuous integration builds. We own Team Foundation Server and could use Team Foundation Build. I'm more familiar with CC.Net and lean that way but management sees all the money spent on TFS and wants to use it.

Some things I like better about CC.Net is the flexibility of notifications as well as the ease of implementing custom scripts.

If you have experience with both products, which do you prefer and why?

Answer 1

I've used both. I guess it depends on what your organization values.

Since you are familiar with CC Net, I won't speak much to that. You already know what makes it cool.

Here's what I like about Team Foundation Build:

• Build Agents. It's very simple to turn any box into a build machine and run a build on it. MSFT got this one right.
• Reporting. All relevant build results (test included) are stored in a SQL database and reported on via SQL Server Reporting Services. This is an immensely powerful tool for charting build and test results over time. CC Net doesn't have this built in.
• You can do similar customizations via MSBUILD. It's basically the same as using NAnt with CC Net

Here's what drives me up the wall about Team Foundation Build:

• To build C++/CLI projects (or run unit tests...?) the build agent must have VSTS Dev or Team Suite installed. This, friends, is just batsh*t crazy.
• It must be connected to the TFS Mothership

If you're in a big org with lots of bosses who have huge budgets and love reports (and don't get me wrong, this has huge value) OR you need to scale up to a multi-machine build farm, I'd prefer Team Foundation Build.

If you're a leaner shop, stick with CC Net and grow your own reporting solutions. That's what we did.

Until we got acquired. And got TFS :P

Answer 2

I'm assuming that as you own TFS you'll be using it for version control. In that case I would lean towards Team Foundation Build. That said, I pretty much agree with Nick.

I wrote the CruiseControl.NET integration for TFS. It works fine and gives you the same build capabilities that you are used to. To me, CC.NET's main advantage is that it is completely extensible and has integrations with all the major SCM and build systems under the sun. The main reason I wrote the CC.NET integration to TFS it is that in TFS2005 the build system did not have out-the-box CI support. However the TFS2008 version is much improved and the team continue to very actively improve it for future releases of TFS.

The main reason for switching to TFS Build would be so that it automatically reports the build information back into TFS which helps complete the software development picture in terms of reporting. It also integrates nicely with the work item tracking side of TFS and inside the IDE (both in Visual Studio and Eclipse).

That said, if you have large investments in Nant scripts that do more than just compile and test your code or you already have a home-brewed reporting solution you might want to stick with what you have.

Answer 3

The real value in Team Foundation Build is that it associates changesets and work items with builds.

This enables a couple of useful scenarios:

• You can look at a work item and find out what build it is included in
• You can look at a build and see which code changes (and work items) it includes

Then of course there's the reports built on top of this information. But even these links by themselves are useful to non-management types.

Have a look at www.tfsbuild.com for "recipes" on different Team Build configurations.