TFS 2010, Is it worth it!?

I’ve implemented source control, issue management and build / deployment strategies lots of times at different companies.  Every time I look at TFS I get very disappointed with the product.  But now my small company is expanding and we’re re-evaluating our source control and issue management environment having grown out of what Unfuddle can offer us.

TFS 2010 has come a long way.  SVN’s outdated branching and merging issues do not appear to be a problem for TFS.  Concurrent development has been resolved (though that come in when they removed Source Safe uck).  Issue tracking and management is no longer an ugly sibling of Windows 3.11 and the workflow looks like it’s actually useful out of the box which is nice for a small agile company like ours.  The build server (Team Build) looks like it’s finally fitting the bill as Microsoft appears to have taken a few tips from some of the more prominent build products on the market (CruiseControl and Team City).  But hey, Microsoft doesn’t invent the wheel they just take the wheel and try to make it their own so it’s no surprise that they’re often a bit behind their competition.

Some of the things I’ll need TFS to do that I’m not sure it can:

1. Automated builds and deployment using MS Build.  We currently do this with msbuild.xml files and need to bring this into TFS’s Team Build server.
2. Dependent or Chained Builds.  We currently require that some processes controlled by the build server run on the successful completion of another build.
3. Unit Testing.  We’re using NUnit, though we’re open to the possibility of moving to MSTest if need be.
4. Import source from SVN.  This one is probably going to be difficult.

There will be a few blog posts in this series over the coming weeks outlining some of the problems I come across and how we resolved them.