TFS Project Organization

Question

I'm relatively new to TFS and am wondering other people deal with organising TFS where there are many projects? For example, does anyone know if it's possible to put TFS projects inside folders or do people use prefixes / suffixes?

Answer 1

When I was first getting started with TFS the Patterns & practices: Team Development with Visual Studio Team Foundation Server guide was helpful. You can put each project at a top level then underneath they have another folder for the trunk and branches for it.

$/Project1
 $/ProjectTrunk
 $/ProjectBranch
$/Project2
 $/ProjectTrunk
 $/ProjectBranch

This is just one example of the many that are in the guide.

Answer 2

We have used an approach that extends .Net namespace hierarchy to indicate similar business areas and map the namespaces to the folder structure.

Namespaces:

Company.AreaA.Project1
Company.AreaA.Project2
Company.AreaB.Project3
Company.AreaB.Project4

Folders:

$/Company/AreaA/Project1 
$/Company/AreaB/Project3

This convention continues also within the projects too.

Answer 3

Project organization is still largely subjective, although it is something that we all struggle with when starting with Team Foundation Server. The ALM documentation is helpful, and there is actually a newer version of the documentation that I would recommend to draw upon. You can get it from the CodePlex at Visual Studio TFS Branching Guide 2010. Even if you do not plan on branching, it is always a wise idea to be in a position to do so, in the event that you need to.

Use the earlier guide, and this newer one, I have a structure that I use as a boilerplate. I will Show you the structure just including the "Main" branch, and if you are use branching, you can understand that everything under "Main" will end up reproduced, as needed, for each.

$/Team Project Root
    /Main
        /Documentation
            /Project A
                {XML Help support - such as Sandcastle projects}
            /Project B
                {XML Help support - such as Sandcastle projects}
        /References
            {3rd party and scripts to install any the GAC, as/if needed}
        /Source
            /Project A
              {Project file, and associated source}
            /Project B
              {Project file, and associated source}
        /Tests
            /Project A
              {Project file, and associated source}
            /Project B
              {Project file, and associated source}
        {Solution Files}

This serves us well, and is meant to be a guideline. You have to be ready to accept that as things change and you use the system more and more within your organization, your needs may change, as well. Let me just tackle each of the top-level folders under Main, briefly:

• Documentation - I have a tendency to use Sandcastle Help File Builder quite often, and have promoted documentation projects to their own level in the hierarchy, like source and tests are.

• References - I have seen people be vehemently on both sides of the argument as to whether assemblies belong inside of Team Foundation Server. I used to be against, but find that this folder structure does not change often, related projects often share a fair number of the same references, and a new developer should be able to get everything that they need in one swoop to get the project up and running.

• Source - Pretty self-explanatory. Related projects, each bucketed into their own folder. Folders, as well as projects, are named by their full namespace.

• Tests - Same as the source folder, but artifacts solely for testing. Usually "Project A" in Source has a corresponding "Project A" in Tests, with the addition of a .Tests as a part of the namespace.

I put all of the solutions under the branch, so it is "one stop shopping" into multiple views into the application. I find it prevents having to always work in one "mega-solution".

As to the branching, you add them as you need them, so not to overwhelm. The guide, linked above, does a really good job of introducing branching gradually, and I agree with the idea to start with a simple structure, and build when the demand dictates. The structure we use works well in a production project, and is also the structure I use in my personal projects.