blog

Project of Projects with team Foundation Server 2010

Published on
5 minute read

It is pretty much accepted that you should use Areas  instead of having many small Team Projects when you are using Team Foundation Server 2010. I have implemented this scenario many times and this is the current iteration of layout and considerations.

Updated 2012-08-06

I have updated this as One Team Project for Visual Studio 2012  .

If like me you work with many customers you will find that you get into a grove for how to set these things up to make them as easily understandable for everyone, while giving the best functionality. The trick is in making it as intuitive as possible for both you and the developers that need to work with it.

There are five main places where you need to have the Product or Project name in prominence of any other value.

Once you decide how you are doing this in each of these places you need to keep to it religiously. Evan if you have one source code file to keep, make sure it is in the right place. This makes your developers and others working with the format familiar with where everything should go, as well as building up mussel memory. This prevents the neat system degenerating into a nasty mess.

Areas

Areas are traditionally used to separate out parts of your product / project so that you can see how much effort has gone into each.

Project of Projects with team Foundation Server 2010  

Figure: The top level areas are for reporting and work item separation

There are massive advantages of using this method. You can:

It is far more likely that a project or product gets renamed than a department.

Tip: If you have many projects, over 100, you should consider categorising them here, but make sure that the actual project name always sits at the same level so you know which is which.

Project of Projects with team Foundation Server 2010  

Figure: Always keep things that are the same at the same level

Note: You may use these categories only at the Area/Iteration level to make it easier to select on drop down lists. You may not want to use them everywhere. On the other hand, for consistency it would be better to.

Iterations

Iterations are usually used to some sort of time based consideration. Here I am splitting into Iterations with periodic releases.

Project of Projects with team Foundation Server 2010  

Figure: Each product needs to be able to have its own cadence

The ability to have each project run at its own pace and to enable them to have their own release schedule is often of paramount importance and you don’t want to fix your 100+ projects to all be released on the same date.

Source Code

Having a good structure for your source even if you are not branching or having multiple products under the same structure is always a good idea.

Project of Projects with team Foundation Server 2010  

Figure: Separate out your products source

You need to think about both your branches as well as the structure of your source. All your code should be under “Source” and everything you need to build your solution including Build Scripts and 3rd party tools should be under your “Main” (branch) folder. This should them be branched by “Quality”, “Release” or both to get the most out of your branching structure.

The important thing is to make sure you branch (or be able to branch) everything you need to build, test and deploy your application to an environment. That environment may be development, test or even production, but I can’t stress the importance of having everything your need.

Note: You usually will not be able to install custom software on your build server. Store any *.dll’s or *.exe’s that you need under the “ToolsTool1” folder.

Note: Consult the Branching Guidance for Team Foundation Server 2010  for more on branching

Project of Projects with team Foundation Server 2010  

Figure: Adding category may be a necessary evil

Even if you have to have a couple of categories called “Default”, it is better than not knowing the difference between a folder, Product and Branch.

Work Item Queries

Queries are used to load lists of Work Items out of TFS so you can see what work you have. This means that you want to also separate queries out by Product / project to make it easier to find the correct data for a particular product.

Project of Projects with team Foundation Server 2010  

Figure: Again you have the same first level structure

Having Folders also in Work Item Tracking we do the same thing. We put all the queries under a folder named for the Product / Project and change each query to have “AreaPath=[TeamProject][ProductX]” in the query instead of the standard “Project=@Project ”.

Tip: Don’t have a folder with new queries for each iteration. Instead have a single “Current” folder that has queries that point to the current iteration. Just change the queries as you move from one iteration to another.

Tip: You can ctrl+drag the “Product1” folder to create your “Product2” folder.

Builds

You may have many builds both for individual products but also for different quality’s. This can be further complicated by having some builds that action “Gated Check-In” and others that are specifically for “Release”, “Test” or another purpose.

Project of Projects with team Foundation Server 2010  

Figure: There are no folders, yet, for the builds so you need a good naming convention

Its a pity that there are no folders under builds, some way to categorise would be nice. In lue of that at the moment you can use a functional naming convention that at least allows you to find what you want.

Conclusion

It is really easy to both achieve and to stick to this format if you take the time to do it. Unless you have 1000+ builds or 100+ Products you are unlikely

run into any issues. Even then there are things you can do to mitigate the issues and I have describes some of them above.

Let me know if you can think of any other things to make this easier.

code-and-complexity tools-and-techniques blog configuration infrastructure nwcadence one-team-project-seriese practices tfs-build tfs tfs2010 tools visual-studio vs2010

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Illumina Logo
Emerson Process Management Logo
Hubtel Ghana Logo
YearUp.org Logo
Alignment Healthcare Logo
Teleplan Logo
Higher Education Statistics Agency Logo
SuperControl Logo
ALS Life Sciences Logo
Kongsberg Maritime Logo
Bistech Logo
Slicedbread Logo
Lockheed Martin Logo
DFDS Logo
Xceptor - Process and Data Automation Logo
Deliotte Logo
Healthgrades Logo
Lean SA Logo
Ghana Police Service Logo
Department of Work and Pensions (UK) Logo
Nottingham County Council Logo
New Hampshire Supreme Court Logo
Royal Air Force Logo
Washington Department of Enterprise Services Logo
Jack Links Logo
Slicedbread Logo
ProgramUtvikling Logo
DFDS Logo
Slaughter and May Logo
Akaditi Logo