TFS: Hundreds of separate applications/projects - what's the best approach?

Question

Let's say that the company has a large number of separate small to medium applications which can be logically divided into a small number of groups.

For example, I can have BMW, Mazda, Honda, Ford .... , Kawasaki, Harley, .... altogether a few dozens or even hundreds of applications.

I think I have 2 options in TFS:

1. Create a separate project for each application. I end up with lots of small projects and can be hit by the limit, but the benefit is that I can have all workitems, bugs, reports etc. assigned separately to each project and have a portal for each project.

2. Create a project 'Cars' and a project 'Motorcycles', and create a source control tree with a branch for each application under each project. That will provide a better structure and less overhead, but I cannot have a portal and a list of workitems, bugs, reports etc. separately for 'Honda' and separately for 'BMW' anymore.

Am I missing something? Is there a way to have both - a separate list of workitems, bugs for each small project without the overhead of creating heaps of projects with the risk of hitting the TFS limit on the number of projects?

Answer 1

I would go with point 2. You can use the 'Areas' section of TFS to assign work items to a particular sub-project.

There is way too much overhead in creating full Team Projects for all those small apps. Does each of those apps need a completely independent life cycle, collaboration tool (WSS site) and set of reports? Usually not.

Worst case you can then create a new team project for any of them if it gets too big to manage, because when you create projects and get to the source control screen, there is an option to 'branch from existing project' so you could just use that to keep your source history and create a dedicated project.

Start agile, scale as needed.