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, rather how you use it on a daily basis. In the area of software engineering where your responsibility not only lies on code but achitecture, documentation and other fields, you need to have a collection of your work, prefferably on the same place.

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

• How would you strucuter a TFS Workspace / Project to support lots of different customers / projects and maybe different projects per customer?
• Splitting up the folder strucutre 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 on Beginners guides, in-depth guides and links covering the above would be very much helpful, please feel free to add other important knowledge-points to this as well.

Answer 1

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.

Answer 2

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.

Answer 3

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