Team Foundation Server – How to Evaluate Moving to Team Foundation Server?

Martin Fowler's little survey says a lot about the state of TFS in previous years. 'dangerous' is quite right. (I think this refers to the way that it doesn't recognise changes made outside of VS, so you can create a WCF project, then use the external svcutil tool to create your client, then check all your changes in.. but TFS will happily ignore your client changes because they weren't made inside VS).

You have to count the cost : the required version of VS to get the goodies - code reviews, for example, require Premium edition which is significantly more expensive if you get VS via MSDN. Also, accessing the system for non-VS users is fine, but if they want the full access instead fo the cut-down web view, then you'll have to shell out for CALs for them. The overall cost of TFS can be quite a lot. Even the recent Forrester report (commissioned by Microsoft, so you have to read between the lines a little) says that TFS requires significant administration support - 2 consultants and 6 admins (who spent 25% of their time) were required to support TFS for their case study of 122 users (works out to 4.5 admins over those 122 users... this is a lot compared to just me setting up and maintaining a full SVN solution whilst also doing my day job). TFS can take a lot of effort to keep working as people expect.

In my experience with TFS2012 (forget previous versions as they're crap), is that is is a very complicated system administer, especially if you step outside the pre-defined setup. For example, if you use MSBuild to build everything, you're fine. But if you have, say, a load of old .vdproj propjects that are no longer supported by MSBuild, you have to edit the huge xaml build script to make it build these projects. After several days working on this, the best I could do was to rebuild the solution by passing it to devenv, and even then, getting the build results out and into the build summary was impossible. Similar results were had by other teams who used NUnit for their tests - if you use the built-in MSTest, then it works. Otherwise, you're pretty much stuffed.

As a user, I find that the integration is more of a nuisance. I prefer TortoiseSVN and I do nearly all of my SCM work via that (as it is an awesome tool). With TFS, you end up with a new screen inside VS for every operation. So you have a new tab in your environment for the team explorer, and another for the builds, and another for each build summary you want to see (and if you want to see the details of a build, an error for example, you have to click through too many links). I found the number of documents I had open when using TFS were more than the source files!

The same applies to checkins, committing changes required clicking through several tabs on the Pending Changes pane in VS to assign a work item and comment to your checkins. Its a small thing, but I found it annoying as I was used to more streamlined tools.

Extending the build system was another area that I found lacking. Adding new features into the build is difficult because of the xaml configuration, and getting the results of those features into your build screens is either very very hard, or impossible. So if you like adding stuff like code complexity or static analysis, or even automated testing via, say selenium, or deployments... forget it. Unless, you are using the Microsoft tools for these aspects (eg fxcop).

Updating the workflow was another niggle - though the powertoys helped tremendously, it was still awkward to get the workflow right,and you still can't configure the scrum board with the information you really want to see - again, you get the defaults or nothing.

Merging was also painful, I think there's a very good reason MS has adopted git for TFS (note this only works with brand new TFS projects, you cannot convert from TFS to git backends).

So all in all, its not too bad as it does work, but I have found a lot of other tools are much better. The disadvantage of those tools is that they don't come fully integrated, but IMHO this is a strength as you can pick and choose the best bits you want. With TFS you get pretty much what someone else wants you to have. If you decide the bug system in TFS is poor (and I think you will), you'll have a hard time changing to a different one.

TFS should be considered along with other big, fat full-lifecycle tools. Most developers hate such things as they dislike the restrictions these tools end up imposing on them.

I would try it though, download the 30-day trials and install it. When evaluating remember to change a little bit here and there, don't just use it for a source code checkin, checkin with a workitem required and get reports based on that workitem. Try assigning a checkin to multiple workitems, and try combining workitems together as related. Try to incorporate something different into the build system, see how to get a daily progress report out of the reporting services, link a document to a workflow requirement and trace it through bug triage to coding to build to rework and then release. Branch and merge a lot. If you can't easily do all these things, then you might as well stick to git. There's not much point to using TFS if you don't take advantage of most of its ALM features.