How to evaluate moving to Team Foundation Server

Question

My development team presently uses the following software in our workflow:

• JIRA
• Bamboo (Atlassian continuous integration)
• Greenhopper (Atlassian agile project management)
• Confluence
• Git, hosted on BitBucket
• Visual Studio 2012

As you can see we are quite heavily invested in the Atlassian ecosystem. We are considering a move to TFS so we can get the niceties of advanced Visual Studio integrations such as code reviews and more importantly the Microsoft Test Manager.

My previous experience with TFS was with 2005 or 2008 (I can't remember) and I have bad memories of it, although not quite as bad as my time with ClearCase.

What criteria should we be looking at in order to properly evaluate our move to TFS?

Answer 1

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.

Answer 2

I've moved from a company with a largely Atlassian stack (and Mercurial) to a company with a heavy TFS stack. I find two irritations.

The first is Source Control.

When you've got used to DVCS, switching back to a CVCS is painful. TFS is particularly painful because, for all that integration to work, it insists on being connected to the server at all times.

However, thankfully, Microsoft have recently allowed for integration of Git version control into the rest of the TFS stack. So you don't need to give up Git, and I advise you not to, given that everyone already knows it.

I'm not yet sure how well the code-review tool works against Git though, given that it seems to rely a lot on shelvesets (a little like stashes, but not so powerful). But then relying on shelvesets for code-review is painful in itself because it discourages regular commits.

The other irritation is the reason most people won't consider moving away from TFS: The Visual Studio Integration.

I have yet to figure out the cognitive reasoning behind this but, in my experience (and taking into account that this is generalising), people who are used to TFS love the integration. They don't like to move outside their IDE for anything.

I, on the other hand, have not warmed to it after a year. I find it cluttered and hard to navigate, compared to having my build server in one browser tab, my tickets in another browser tab and so on. (Edit: As Andrei notes, there is a web interface, but it is also inexplicably clunky, when you're used to more recent versions of Jira and Jenkins. But still, it does at least work in browsers other than IE now. So that's something.)

I never look at builds unless I'm trying to do one, and then I find it hard to find out if someone else is already doing one. I don't see other people's changes unless I'm asked to review.

But, your milage may vary. As I say, some people seem to find it indispensable. I just can't help noticing that it's generally people who have never done it another way.

Also, don't fail to notice that this is 2 negatives, one of which may be personal, in a pretty large infrastructure. Most of my experience is good and TFS isn't as bad as some people will have you believe. And most things you find you're missing can probably be switched on (it's very configurable); given that you're moving a whole team, rather than one person, you might find less resistance.

Answer 3

I have a very positive experience of using TFS 2012. It is quite easy to set your TFS server up and running, CI build automation is very simple and straightforward (and the Gated check-in build is just awesome. We failed to achieve same functionality with Team City). Team interaction is very transparent and straightforward too. You can easily associate your check ins to TFS workitems, manage a backlog, track defects, do codereviews and so on. There is even a messenger build in =)

However keep in mind that if you accustomed to your JIRA's workflow, setting up TFS workflow could be a tough task. I'd suggest adopting one of the predefined TFS workflow. Also you will have to keep Confluence as you knowledge base or switch to SharePoint as there is no wiki build into TFS.

TFS is much more cheaper if you have a MSDN subscription (I believe most developer companies working with MS technology stack have it) in that case you have TFS for free.

I think there is no reason to keep using side parties tools if you all your developers are working with Visual Studio. TFS provides integrated, robust yet easy to use ALM system. I will gladly answer your questions if you have any.

Answer 4

I thought it would be worthwhile updating this question with some thoughts from the end of 2021.

When I asked this question almost a decade ago, Git was nowhere near as widespread as it is today and if I remember correctly there was minimal integration in Visual Studio.

I started a job in mid 2014 that was heavily invested in the Microsoft ecosystem, including TFS. TFS proved to be a pain for multiple reasons:

• Workspaces are a complex solution for a simple problem
• Exclusive locking is a pain
• Requiring connectivity is likewise a pain, if the WAN drops or the server goes down, you can't check a file out to edit
• Resolving disconnected changes is a manual process
• Branches are a heavy-weight object and generally long lived
• The permission system is great for an Enterprise with 100k+ employees but makes little sense for a small to medium sense shop
• Code reviews, at least in the version we're using are painful and we usually resort to putting review comments in the code
• Merging is incredibly painful. Nothing like Git.

We've been moving new development to Git, initially with Azure DevOps and also Github. I find the PR management on DevOps to be a better experience than Github, but both are leagues ahead of TFS.

TLDR Comparing TFS to Git (which is absolutely the choice to make in 2021) is like comparing XML/SOAP to JSON/HTTP. TFS has some pretty powerful features but given Microsoft never widely adopted it (stuck with Perforce before moving to Git) should tell you all you need to know.

Answer 5

Peoples should know, TFS is not just VCS, it is ALM.

Seem many peoples just want a VCS but go for TFS is wrong way.
For CVCS, I still prefer SVN.
For solo or open source, sure go for GIT.

But TFS2012 is not bad, it is easy understand on merge/fork then SVN.
And team foundation service is free for 5 user / unlimited,private repo.

Client is free too, TFS explorer build on top of VS2010 and it is free.
For Eclipse, it has Eclipse plugin - TFS everywhere.

I don't see any cost problem on that.
TFS express (free) can be work with SQL Server Express (free too).