Team Foundation Server - A programmer's guide

Question

In addition to my Previous topic on

How to use SVN, Branch? Tag? Trunk?

I would like to get in-depth on how a programmer should/could use TFS.

The things that are most interesting to me is not how to set up the server but how you use it on a daily basis. In the area of software engineering where your responsibility not only lies on code but architecture, documentation and other fields. You need to have a collection of your work, preferably in the same place.

So these are my points of interest which I would like to get more knowledge about:

How would you structure a TFS Workspace / Project to support lots of different customers / projects and maybe different projects per customer?
Splitting up the folder structure on the above project into different pieces such as, Code, Documents -> Architecture, Requirements and other, what more could there be and what would be a nice commonly used folder structure?
An easy to browse repository; Again the folder structure here is important however this point is more aimed at different Explorers for the repository, not only the built in Team Foundation Explorer.

These are just a couple of the points that I would like to know more about. Suggestions for beginner's guides, in-depth guides and links covering the topics above would be very much helpful. Please feel free to add other important considerations to this as well.

I would love an answer to your first bulleted question, using workspaces to manage multiple projects per customer. — Ryan Rodemoyer, Mar 05 '11 at 20:08

score 13 · Accepted Answer · answered Jan 02 '10 at 18:44

As already mentioned, the Patterns and Practices guide is a great guide for the whole of using TFS.

http://www.codeplex.com/TFSGuide

However, if you happen to want to focus on branching strategies, you may want to also check out the branching guides (especially the second version) that the VSTS Rangers put together.

http://www.codeplex.com/TFSBranchingGuideII
(older version) http://branchingguidance.codeplex.com/

If you end up getting into specific questions that aren't covered by the above, keep in mind you can hit the TFS Version Control forum for help, too.

http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/threads

score 8 · Answer 2 · answered Dec 22 '09 at 09:55

Have you referred to this guide: http://www.codeplex.com/TFSGuide

I just got through writing a TFS guide for our company and we followed most of the best practice recommendations from that guide.

The structure we are using is this:

TeamProject1
    Main
        Source
            ClassLibrary1
            ClassLibrary2
            CommonCodeLibrary
            TeamProject1Web
    Releases
        Release1
            Source
                ClassLibrary1
                ClassLibrary2
                CommonCodeLibrary
                TeamProject1Web
        Release2
            Source
                ClassLibrary1
                ClassLibrary2
                CommonCodeLibrary
                TeamProject1Web
TeamProject2
    Main
        Source
            ClassLibrary1
            CommonCodeLibrary
            TeamProject2Web
    Releases
        Release1
            Source
                ClassLibrary1
                CommonCodeLibrary
                TeamProject2Web
        Release2
            Source
                ClassLibrary1
                CommonCodeLibrary
                TeamProject2Web
SharedTeamProject //this would represent a set of code that's used in other team projects
    Main
        Source
            CommonCodeLibrary
    Releases
        Release1
            Source
                CommonCodeLibrary
        Release2
            Source
                CommonCodeLibrary

Basically, we branch the Main\Source project to the Releases\Releasex branch when it's time to do a release.

For code that's shared across multiple projects, we create a separate team project for that code and then we branch it into the individual team projects. In the example below, SharedTeamProject represents shared code. We would branch CommonCodeLibrary, for example, into teach of the Main\Source folders for the individual team projects.

For customer specific releases, you could just create the proper release branches for them.

I think the main thing is to come up with a scheme that your team agrees (mostly) on, understands, and is willing to follow. Make sure that scheme is documented well and that it's followed. Consistency in structure is one of the keys to a successful source control system.

Where do you store other data than Code? You don't have that in your strucutre above. — Filip Ekberg, Dec 22 '09 at 11:31
@Gerrie - I disagree. Did you have a look at the patterns and practices guide I linked to? Please refer to Chapter 5 and you'll see that this is one of the patterns Microsoft endorses (see Scenario 2). @Fillip - You can create other folders as necessary, but the idea with TFS as oppossed to SVN is that project level documentation is stored in share point portal. When you create a team project, a share point portal site is created exactly for this purpose. That's one of the things that confuses a lot of people coming from SVN to TFS, the paradigm is a bit different. — dcp, Dec 22 '09 at 11:50
@dcp This might be true in simple scenarios, but if you have two teams working on the same code to implement two separate new functionalities, you'll need one or more development branches. — Gerrie Schenck, Dec 22 '09 at 12:12
@Gerrie - I see your point, and agree with it. I think it depends on your shop/team size. I work in a fairly small shop, so the aforementioned structure works well for our team. In the scenario you mention though, you would definitely need more branches. But they do cover that scenario in the guide I linked to. Bottom line is just use what's best for your team :). — dcp, Dec 22 '09 at 13:19

score 3 · Answer 3 · answered Dec 22 '09 at 09:51

Here's what I think about your points:

First of all there is the Team Project level. It's best to follow Microsoft's recommendation here: physical teams have separate team projects. For customer-specific changes I'd make extra branches from the trunk. This allows you to merge all bug-fixes and customer-independent changes to the customer branches without too much hassle.
Don't put documents in source control, put them in the Documents folder which can be found in the Team Explorer. For all documentation I'd say check out Sharepoint.
Try to map your folder structure onto your namespace hierarchy. This makes things extremely easy to browse.

Keep in mind setting up TFS really depends on the size of the teams, the number of teams and the size of the codebase.

Could you provide some examples as the other poster did? It's easier to see how others strucutre their work that way. Thanks for the input. — Filip Ekberg, Dec 22 '09 at 11:31

Team Foundation Server - A programmer's guide

3 Answers3