+2  A: 

The benefits of TFS are one integrated environment that is supported by Microsoft. I personally do not like TFS for source control and have had a number of issues with it. It is clunky, however it had the benefit of having VS integration (which is also available in VisualSVN, but is not as robust).

Personally, I think you would be much better off using SVN/TeamCity. It is just easier to work with and behaves more as you would expect. As with most open source software, both are constantly evolving and will always have the latest and greatest feature before Microsoft. The integration between the 2 is really good and I have found no fatal flaws in the system. I constantly push to go this route in my current company (we use TFS), as I believe it is a much better workflow. As an added benefit, it is significantly cheaper than going the TFS route.

I have also used FinalBuilder with TFS - my question there is what are you really buying with FinalBuilder that you can't do with NANT/MSBuild? The answer at my shop is unfortunately very little IMO.

Keith Rousseau
Thanks for the response. Awesome to hear from someone who has actually used both systems. As for your question - since I am just in the proof-of-concept phase of setting up our TDD infrastructure, I'm not quite sure if FinalBuilder is worth using yet. From what I've read though it makes it much easier for creating the build scripts and people have had high praise for it - did you not find that it was much better then having to edit the build scripts by hand?
dferraro
It probably has a lot to do with the setup that we have for FinalBuilder, but we have run into a bunch of issues because assumptions about our folder structure for solutions were made in the past that are no longer true. So our FinalBuilder script has become a beast that does a ton of different things. I don't see that it has provided a ton of benefit to us above and beyond what we would be able to do with NANT alone.
Keith Rousseau
Good to keep in mind. FinalBuilder seemed like a great sell - no having to write your own build scripts and just push buttons. Guess its still a bit immature for certain setups. But I've heard it plays well with TeamCity from people whove used it. Maybe TFS is the blocking factor for you?
dferraro
Yeah a fair number of our issues certainly come from TFS. I think that our FinalBuilder script also is trying to be too many things to too many people. We really should have split it out into a couple of different scripts for different types of projects.
Keith Rousseau
+2  A: 

First off, see this post:

http://stackoverflow.com/questions/4219/experience-with-svn-vs-team-foundation-server

As to your question about which environment better fosters TDD and such, my two cents is that the build management system matters much less than what's in the build file itself. Your Ant or MSBuild file should have the targets that do your testing. With MSBuild or Ant, you don't have to use MS's test suite. You can still use nUnit or whatever else you want. That means it doesn't matter if TFS is calling your MSBuild file, or if CruiseControl is, or if TeamCity is. The smarts are all in the build file and the tools you integrate with it.

My personal choice is not to get locked down into TFS's way of doing things, since you have a lot more freedom for a lot less cost with the wealth open-source testing tools that are out there. TFS is about to receive a major upgrade, as well. If you are going to go with TFS, my advice is to at least wait until 2010 is released. Concentrate on making your MSBuild files as good as they can be right now.

That being said, I must admit that TFS has one of the nicest build systems out there (2005 was terrible, 2008 was nice). Being able to easily customize notifications and the release process all inside .NET code was pretty cool -- you had a lot more central control over build and release policy than we did with CruiseControl.NET.

So I've used TFS and SVN/CCNet. I can't speak much to TeamCity. But IMO a build management system should be fairly agnostic to what is being built and how it's being built. For us, the extra control in the release management process that TFS brought us just wasn't enough of a bonus for us to justify the greatly increased administrative effort of a fully integrated TFS solution. Nor was it enough to justify the extra per-license cost of TFS, which can be significant.

Dave Markle
You bring up a good point about the increased overhead of maintaining a TFS solution. If you really try to use TFS to its full ability, you will need at least one person whose full time job is a TFS admin. Of course, you can get by without that, but then does TFS really justify the cost.
Keith Rousseau
thanks for the good info. Unfortunately, from my 6 or so years experience in commercial LOB software, management almost always runs away and hides from anything with the word 'open source' near it. I guess i'll never understand why... if you hid it from them that its open source, theyll never notice... ;)
dferraro
+8  A: 

We are a small development shop, and decided that Team Foundation Server carries too much overhead for us. We used to write custom MSBuild scripts to run from the command line, but after we discovered TeamCity, we moved our entire build process over to it.

We've found TeamCity to be easy to use and configure, and JetBrains provides excellent support and documentation. They are also on a much faster release and update cycle than Microsoft.

Their support for SVN source control is excellent, and we like the fact that they support both MSTest and NUnit for unit testing.

We also liked the fact that the TeamCity Professional edition was free, so we could evaluate it to see if it worked for us. We haven't hit the number of project configurations (20) that would require us to upgrade to the Enterprise edition.

dthrasher
Thanks a lot for the post. this is very useful to hear from someone who moved FROM TFS TO TeamCity. Out of curiousity - Are you guys a strictly Microsoft shop though?
dferraro
I wouldn't say we were strictly Microsoft. We mostly work with .NET technologies, but are willing to look outside the Microsoft stack for other useful tools and technologies. I guess that puts us in the Alt.NET camp. :)
dthrasher
We also moved from TFS to TeamCity + Subversion + VersionOne. First, we ran into serious problems with source control under TFS. Then, after experiencing some project management pain with TFS, we were told by a major MS consulting shop that we should adjust our methodology to fit the MFS-Agile process template! At that point we migrated away from TFS and have never looked back.
Duncan Bayne
+5  A: 

This question has a lot of good answers about TeamCity. It does not compare to TFS but it might shed some light on TeamCity for you.

I have used both, and I have had success with both, but TeamCity was so much easier. It was a breeze to set up and configure. TFS was not. It's rock solid, it's easy to maintain and it just plain works. The developers at JetBrains have done a great job responding to the community. They get a release out every 6 to 8 months that adds real value. TFS is on a 2 year or more cycle.

TeamCity gives you more choice in how you build and what source control you use. It's not all in one, but that's sometimes a good thing. It's got a good set of extension points as well. We have also been really happy with the agent model it has.

I've gone through 3 absolutely painles upgrades in TeamCity. The one TFS upgrade we did took our build and source control down for 3 days. I'm the admin for TeamCity on our project and it takes up a couple of hours a month. TFS took a couple of days a week.

TeamCity + SVN + VisualSVN has been the smoothest environment I have ever worked in. TFS was generally smooth on the day to day, but only if someone was there keeping it running.

Hope that helps

Mike Two