In light of the recent TFS vs. OSS debates, I wanted to share how we are using both TFS and OSS tools to work with each other.  Speaking as someone who has implemented (and extended!) TFS in a production environment since the early Beta 2 days and am currently using the VSTS/TFS stack, I can say that there is quite a bit of pain involved.  But some of that can be alleviated by utilizing both commercial and OSS tools *with* TFS.  Here are a few examples of how I (and some of our team) are "filling in the gaps" to make TFS and VSTS a little easier to work with.

Testing

I think it's pretty clear that the integrated testing that comes "out of the box" with VSTS is sub-optimal (I'm being nice... :) ), which I covered in a previous post.  I've seen first hand how much of a hindrance it can be due to its poor performance which negatively affects that all important rapid feedback cycle.  Not to mention it encourages developers to adopt bad habits and continue to tether themselves to the VS2005 IDE.  Using NUnit, or even better, MBUnit, can really speed up your tests.  But sometimes we find ourselves in an environment where we don't have a choice but to reference the *.UnitTestFramework.dll and use the MSTest attributes for the sake of those on the team that prefer using the integrated testing environment in VSTS.  Well, there is still hope as shown below...

Here are a few tools/tips you can use to get that rapid feedback without disrupting the rest of the team:

• TestDriven.NET Plugin - In case you've been living in a hatch on an island with a guy named Desmond for the past couple years, this plugin is the fastest way to run your tests in the IDE, period!  Wire it up to Ctrl-T (tip from my friend, Paul), and you'll be on your way.
• NUnit - Just the old skool NUnit will work as well since it "knows" how to interpret the MSTest attributes properly.  Either the console or GUI, pick your flavor; more on the console version next...
• "Green Screen" - 'Cause it still feels good sometimes to be sitting a command prompt to get your work done (kermit green on black being my preferred color scheme).  On a related note, I think this (along with many other things) is why I'm referred to as a geek multiple times a day.  :P  Console2 is a great way to have multiple console windows open in tabs.  For the past few months I'm finding myself utilizing my automated build script for a majority of my testing needs.  The advantages of this are:
  • it's crazy fast 'cause you can have much more control over how you do compilation instead of relying upon VS for compilation which is about the slowest possible way
  • it'll force you to, at the very least, automate your compilation and testing which can then be re-used on a daily/CI build server and this has the added effect that when you do your "check in dance", you can run the exact same testing target that the CI build server uses 

Continuous Integration / Automated Builds

TFS comes with a product called Team Build, which is their "out of the box" automated build server.  I think it has a lot of potential in future versions, but this first version I've found to be lacking some key features and in general is just a pain to get up and running.  Some of the things I hope are addressed in future versions are:

• Boy, is it slow.  Of course slow can be a relative term, but in comparison to something like CruiseControl.NET, it's painfully slow.  I've seen it consistently take as long as 20-30 minutes just to get the latest source, compile and drop the binaries.  Now, this was a fairly large project consisting of multiple solutions, maybe 30-40 projects in all.  And it was using the default compilation options in MSBuild against the solutions, which as noted above, is probably the slowest way to compile code.  So a lot of the slowness may have been caused directly by MSBuild.
• Unless they've changed or issued a patch for this, I had problems trying to run more than one Team Build "build type" at a time on the same server.  This seemed very odd to me and would definitely rule it out as a continuous integration server, if you want host multiple projects on the same CI server, which is often needed.
• No scheduling!  Another likely showstopper.  Almost enough to not be able to call it an "automated" build server.  Of course you can use the OS's built-in scheduled tasks to shell out to a batch file and run it on a scheduled basis, which works.  But the lack of sophisticated triggers and scheduling system needs to be addressed.

Fortunately, it looks like a lot of these issues can be addressed now using various tools like Automaton and CI Factory, which I've heard great things about, but have never personally used either of them.

Another option is to just use CruiseControl.NET as your automated build server.  This is an established product and isn't plagued by any of the problems listed above.  It's fast, can run concurrent builds on the same server and comes with some very flexible scheduling options.  It has support for most testing and code metric tools out there, including MSTest, if you must use it.  And in combination with the dashboard and CCTray application, it makes for a great continuous integration environment.  I've set up some pretty complex build environments using CCNet with TFS, so this is another example of how OSS tools can be used alongside TFS.  Just grab the TFS source control plug-in for CCNet, and you'll be on your way.

Even though Team Build has it's limits, I'm looking forward to see what Microsoft is planning for future versions.  It has the potential to be a very powerful automated build / continuous integration server.

TFS Work Item Management

For the most part, using TFS to manage requirements and tasks as work items works pretty well.  The ability to link work items to check-ins probably being the most interesting and useful feature.  You can also link work items to other work items, which make it a decent candidate practices like Scrum where you have a product backlog of high level features and more granular sprint backlog items that link back up to the high level product backlog item. 

One problem with this though is that you can't easily see a hierarchical representation of this data.  This can make it difficult to quickly identify the relationships between work items.

Well, a co-worker of mine has started an OSS project on CodePlex called TFS Work Item Explorer.  This has some interesting potential to give an alternate view of your work items in TFS.  I believe his latest release even has the ability to update work item data.  Definitely worth a look if you feel limited in the data grid style view of work items in TFS.

Well, I guess that's it for now.  Hopefully this will help some of you folks who are struggling with TFS to look at possible alternatives to complement your use of TFS as a way of managing projects.  The good thing is that most of these can be used without interfering with those who want to just use the "out of the box" components.