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?
We've been using CruiseControl.net since June '07 and it's worked great for us. Best part, it integrates to SVN easily which is a far superior source control provider.
So our setup is:
We've had some major parallel development going and the branching and merging experience was spectacular. If you have the choice I'd go with the setup above!
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:
Here's what drives me up the wall about Team Foundation Build:
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
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.
The real value in Team Foundation Build is that it associates changesets and work items with builds.
This enables a couple of useful scenarios:
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.
SVN is an OK tool far superior is not true, SVN vs. TFS is similar to a Ford pickup vs a Mercedes 500, it gets the job done but it isnt pretty nor is it comfortable, the merging has a lot to be desired. I prefer the TFS merging tool as it seems like the branching dev is right there working with you, that is how smart it is. Our internal SVN seemed to get corrupted a lot, this is the reason we ditched it and went to TFS and have not looked back. The shelving of changesets is wonderful for an agile development shop, currently have 270+ engineers on TFS with no issues or problems, SVN simply was not capable of handling that kind of load without someone having issues.
I prefer CC.NET simply because of tools we have developed in house to extend the functionality in reporting and administration. TFS build is very closely integrated however and we anticipate a switch when we upgrade to SQL 2008