10

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?

  • 4
    I moved from a company on git to a company with TFS 2008 and it is incredibly painful. I hear 2012 is much nicer.. but we aren't in a position to upgrade at the moment. As it currently is though... I would kill to go back to git :( – Simon Whitehead Aug 16 '13 at 8:30
  • 1
    That's correct. TFS 2008 was hard both to maintain and to use. But there is a strong positive tendency: TFS 2010 was much better then 2008, TFS 2012 is just as much better then 2010. It's much more maintainable and has great web interface so it can be used by people without Visual Studio (testers and product owners, etc) – Andrei Zubov Aug 16 '13 at 9:21
  • @SimonWhitehead as someone who moved from TFS2008 to TFS2012, the differences at a fundamental user level aren't much changed - there's new bits round the edge (eg code reviews, scrum web page, etc) but you'd still hate it. Upgrading ... forget it, you need to do a clean install and copy your data in. – gbjbaanb Aug 16 '13 at 14:31
  • 4
    Even TFS 13 has nothing to compare with JIRA Agile. Their current "Kanban board" implementation is a pathetic attempt to bring life to this dead-born child. To replace Cofluence you will find nothing at all. I am not sure why anyone should consider moving from Atlassian stack to TFS stack. I am using TFS for many many years and I was never happy with it, neither my colleagues were. – Alexey Zimarev Jan 27 '14 at 13:58
  • As you're already invested in the Atlassian ecosysten, I'm surprised no-one has mentioned Atlassian Stash, which runs on top of Git and gives you features such as repository access management, pull requests, code reviews and automatic merging strategies. It's quite nice. – Mike Chamberlain Mar 19 '15 at 3:01
17

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.

  • 1
    Thanks for sharing your experiences and its good to get some negatives. I used ClearCase a while ago in an enterprise and that was the worst SCM I have ever used. The administrative overhead is concerning, we're a small startup but I really love that our current setup requires practically no administration. – Sam Aug 17 '13 at 1:46
  • Serena Dimensions was the worst I ever used, Clearcase didn't seem nearly so bad in comparison, at least it worked! I think MS wants you to go with their cloud version of TFS, self-installed is something they can sell to corporates for big bucks. I'd stick with what you have. Get some more tools to give you the same functionality (eg ReviewBoard). – gbjbaanb Aug 17 '13 at 19:51
  • oh, and I know its a bug so its not really fair to highlight it - but if you try the code review feature of TFS, and you try to review a file that has been renamed as well as modified, TFS will report a "previous revision not found" error. If you do a lot of refactoring, this may be a problem. It might be a little bug, but then it might also be a major architectural problem if they don't track file renames in the TFS back-end store. – gbjbaanb Aug 17 '13 at 19:53
  • 2
    Sorry for the late reply, it was ultimately you who talked me out of using TFS. Thanks. – Sam Aug 21 '13 at 4:10
  • 1
    Good to hear it - everyone seems to think they must use TFS, when really we all should be using a wide range of tools. Otherwise we will end up with only 1 or 2 companies that provide all our IT tools... Microsoft and Oracle... that would not be the nicest world to live in :) Atlassian do good tools, more people should evaluate them. – gbjbaanb Aug 21 '13 at 10:44
12

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.

  • 1
    This is basically what I would have answered with. Glad to know I'm not the only one! – Simon Whitehead Aug 16 '13 at 14:35
  • 1
    you can do code review of committed code, but you just know the fact that you can prevent checkins until after review means people will use it exactly like that. Corporate policies everywhere will be written so this is mandatory, and then it'll become another process bottleneck to piss developers off. – gbjbaanb Aug 17 '13 at 19:56
5

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.

  • 1
    thanks very much for your feedback. We're using BizSpark which I am fairly certain has TFS included. I guess the only thing I'd like from you is any negatives, just to weigh it up. I'm happy to stay with Confluence as I really dislike SharePoint. – Sam Aug 16 '13 at 9:02
  • The change notification system in TFS is somewhat simpler the in other solutions (Test Track for example has much more robust system). In TFS you only get notifications if workitem is assigned to you, you can not subscribe to changes on specific workitem for example. I think its not a big problem in an agile work process, but if you rely heavily on notifications in your work process it may be a pain. Source control will require some time to get used to. Especially if you accustomed to GIT command-line commands. But the branching visualization is worth the efforts I think. – Andrei Zubov Aug 16 '13 at 9:15
-3

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).

  • 1
    how does this answer the question asked? – gnat Sep 2 '13 at 12:33

protected by gnat Mar 19 '15 at 15:58

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.