TFS is destroying your development capacity

home
team system
view story

8 Kicks

TFS is destroying your development capacity(www.derekhammer.com)

submitted by genki(69) 8 months, 14 days ago

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

7 comments |category: Team System |Views: 304
Tweet

tags: TeamSystem another

Everyones tags:

Your Tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

snaits(197) -

BILE_GRAN_CORREA(0) -

Bile0Gran0Vieira0Correa(0) -

bsenoff(1583)

More who kicked this story...

Comments:

posted by dpeterson(4397) 8 months, 14 days ago +1

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.

posted by vijayst(1311) 8 months, 14 days ago +1

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.

posted by dpeterson(4397) replied to vijayst(1311), 8 months, 14 days ago +1

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?

posted by vijayst(1311) replied to dpeterson(4397), 8 months, 14 days ago +1

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.

posted by dpeterson(4397) replied to vijayst(1311), 8 months, 14 days ago 0

Good point, does that work even if the solution file is read-only?

posted by vijayst(1311) replied to dpeterson(4397), 8 months, 10 days ago 0

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.

posted by dpeterson(4397) replied to vijayst(1311), 8 months, 10 days ago 0

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.

Most Active Users

What's this?