<< Quick note RE: Euler problem 13 | Home | ObservableCollection Extensions >>

Migrating to TFS – or should we??

In my previous developer roles I’ve gradually migrated into being the Source Control Guy, the one that runs the Source Control and generally chooses which one to use. At the same time, I generally get the option of picking the Bug tracking software.

Admittedly, typically this is coming from an existing Visual SourceSafe (VSS) system with no bug tracking, to something else, which by anyone’s standard is an improvement, (for those who want to know I’ve typically gone with SourceGear Vault as the SCC, FogCreek’s FogBugz for the tracking, (and for completeness) CruiseControl .NET for the Build Server).

I’ve never attempted to recommend a TFS system, for a couple of reasons, most times it’s seemed a bit too heavy handed for what we’ve been doing, and the classic business issue of cost. Now, I appreciate that I may (as most people in the development world) have misunderstood the cost, but what matters is how it’s perceived.

Anyhews, I’m currently in the situation where I actually have access to a TFS server and we’re evaluating the benefits of moving our existing codebase to the TFS system. Currently we’re using Subversion for the source control (perfectly good), JetBrains’ TeamCity as the build server (again – nice) and Service Desk for bug tracking (ugh).

Now, the big question here isn’t what can TFS give us over the current situation, (improved bug tracking, reportability, better handling of MSUnit tests – In silverlight), but is there enough improvements to justify the upheaval? And it is an upheaval, switching source control is bad enough, switching source, build and bug in one hit is expensive in terms of time and mental switching.

But the elephant in the corner is What about other solutions? We already have SVN and TeamCity (albeit the free version), why not simply improve the bug tracking with something like JIRA or FogBugz? Is going wholesale one route correct?

Another elephant (so to speak) is developers not on the Microsoft stack, Java developers for instance. Can TFS work well for them? Would it be more of a hindrance? I know things like Team Explorer Everywhere, and Subversion clients both work with TFS, but do we lose anything using it that way?

So many questions…

Meh.

Print | posted @ Thursday, July 15, 2010 4:37 PM

Comments on this entry:

Gravatar # re: Migrating to TFS – or should we??
by Kurt at 7/15/2010 10:09 PM
The main arguments for TFS seem to be "integration", and how dominated by Microsoft the culture is. For some reason I prefer many smaller specialist tools rather than one all encompassing integrated tool. For me the best integration happens on the command line, where you can script things together. The integration is also a red herring. The same people that need source control are not exactly the same people that need an IDE (for example our acceptance test writers need to install visual studio just to use source control), who are not the same people who need to enter and maintain work items.

As far as non MS devs, we had a python web apps team that were able to use it, but it was uncomfortable. When you work from a visual studio solution, files are automatically checked out, when you don't you have to manually do that. Our python people ended up using mercurial, and then integrating it upstream into TFS.

I am not a TFS fan, but it is probably more of a matter of taste, culture, and philosophy rather than a reasoned objective evaluation. We use it at work, and it works, but I would prefer git. I think the main reason we use it is because we are MS gold partners, and have invested in the whole ecosystem.
Gravatar # re: Migrating to TFS – or should we??
by Kurt at 7/15/2010 10:11 PM
Forgot to mention. I like what Martin Fowler wrote about source control tools:

http://martinfowler.com/bliki/VersionControlTools.html
Gravatar # re: Migrating to TFS – or should we??
by Paul at 7/16/2010 10:02 AM
Good post Chris, in my new role I've just been looking at exactly the same thing! TFS is surprisingly cheap, so for me it is looking like it will be the option that wins. We're probably a little way from making any decision / getting any thing rolled out. Let me know how it goes if you go the TFS route and get something set up.
Gravatar # re: Migrating to TFS – or should we??
by Ryan at 7/17/2010 7:55 PM
Based on my own experience and the stories related to me by my friends at other companies, I would highly recommend NOT using TFS. If you are already familiar with the SVN workflow, going to TFS will turn your world upside down. My company has migrated from TFS to SVN to Mercurial (Hg). We absolutely love mercurial because of the ease of branching and the ability to work remotely (without a VPN connection). We also have had fewer merge conflicts using Hg than with SVN. I use Git on my personal projects, but that's because I use GitHub for hosting.

I don't see any real reason to keep all your toolsets under one roof. We use AgileZen for project management. We used to use Mantis for bug tracking but we've ended up developing a bug tracking workflow within AgileZen so we've mostly migrated to that. We use CruiseControl for continuous integration.

If you are looking into different VCS systems, Martin Fowler has a nice write up. http://martinfowler.com/bliki/VersionControlTools.html
Gravatar # re: Migrating to TFS – or should we??
by Matt at 11/25/2010 6:22 PM
On what basis does this comment come from - "TFS will turn your world upside down".

The posts here seem to be overlooking a very important point. Having the integrated view of development tasks, requirements, features and bugs associated with source change sets is very powerful in terms of quality control and change management.

What I like about TFS having used it on and off for last 4 years is can use it simple out of box mode or you can customise and change workflow, add new fields, define custom security etc. Very quick, easy to export to Excel, Project where you can send off documents get items edited and then publish back to TFS. Additionally the reporting is extremely powerful and really shows if projects are tracking well.

Seems like others make a project / goal out of trying to put in a mix of other solutions and getting something that comes close to TFS. I think the concern they have is vendor lock in. But in my experience it is easier to switch from "one" vendor to X other vendors than it is to switch from many vendors to many other vendors.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: