TFS is destroying your development capacity

added by genki
9/12/2011 9:14:15 AM

7 Kicks, 453 Views

Author explains some of the perceived shortcomings of TFS and what solutions exist that can eventually replace the functionality of TFS. Basic premise is that TFS is a tool that promises to do everything, but in actuality does it all poorly (and doesn't talk to anything else).


4 comments

dpeterson
9/12/2011 9:14:49 AM
I honestly didn't realize that TFS was this bad, particularly with regards to locking all files as read only if the developer loses network connectivity. Even VSS got that right, and I would never go back to using VSS.

vijayst
9/12/2011 10:21:00 AM
TFS works well with a process template: MSF for Agile, MSF for CMMI. MSF defines iterative phases like Envision, Plan, Implement, Build, Stabilize, Deploy. Also, MSF defines peer roles like Program manager, Product manager, Architect, Developer, Tester, Release Manager. TFS is a good implementation of MSF.

With TFS, the product manager can create work items. The architect or developer can create tasks. A project manager can sync these tasks into a Microsoft project file and prepare a schedule. This schedule can be uploaded back into the team system. The tester can create test cases against the requirements. The test results can be recorded in TFS either manually or using Test manager. Loads of reports can be created from TFS like progress of the project, and quality of the product.

As a version control system, it has a few shortcomings. But, there are work-arounds to them. There are various tools that are built around TFS. One of them is TFS Shell extensions. This allows TFS to work more like SVN. If you do not like TFS integration from Visual Studio, you could use TFS Shell extensions.

I do agree that a lot of training is involved in getting to understand TFS. Also, most organizations do not like TFS because of Vendor lock-in or they already have existing systems to do requirements management, test management etc.

If the organization is working on Microsoft .Net technologies alone, TFS is the way to go.

dpeterson
9/12/2011 10:54:57 AM
But what do you do when there is no access to the TFS server, if the server goes down and has to be restored, no one in the company can get any work done correct?

vijayst
9/12/2011 11:03:16 AM
It is possible to unbind the solution from source control temporarily. This will ensure that developers can continue to work when the server is offline: http://msdn.microsoft.com/en-in/library/ms181375.aspx.

dpeterson
9/12/2011 11:04:13 AM
Good point, does that work even if the solution file is read-only?

vijayst
9/16/2011 8:43:22 AM
I did some research on this. When TFS server is down, the developer can continue to work on the files that he already checked out. The catch is that he will not be able to checkout files when TFS is down.

If TFS is down, it is not possible to unbind the solution from the source control. So, the previous comment from me was a mistake.

If TFS is deployed within the intranet environment, it will hardly go down unless there is a planned maintenance. In the case of maintenance, the developer will be notified well in advanced. In case of server restarts, there will be a loss of availability. Bringing TFS online after the restart hardly takes a second.

If availability is a concern, (and for some reason, TFS server has to be maintained continuously), the integration with TFS should be done in an offline mode. Developers should have a clone of the TFS source (just like SVN). The working project should be a different one. And check-out/in should be done whenever required.

dpeterson
9/16/2011 8:46:28 AM
Don't forget about server crashes, in my experience they happen more often than scheduled maintenance ;).
Thanks for doing the research on this, in my mind it justifies my choice to stick with distributed source control solutions.