Suggestions for Organizing Project Collections and Team Projects

Our company has decided to start using Team Foundation Server 2010 for our development process.

I am having trouble deciding on how to structure our Collections and Team Projects.

We have a total of 9 developers, all working on different projects at different 开发者_开发问答times.

It seems like half of what I read says to use as many collections as you want, while the other half says to limit the number of collections.

What is your approach when creating/managing several projects that don't necessarily interact with each other? Is it best to put stuff in separate collections or is it wise to keep the number of your collections low? Any help is appreciated.

I personally wouldn't muddy the water with a lot of collections here. A default collection with a Team Project for each thing the developers would be working on would be fine.

Each "Default Collection" is kind of like a separate instance of TFS (running within the same environment). The idea is that collections don't cross over each other, and all of the data always stays separate. If I recall correctly (can't test right now because we're still on TFS 2008), you would actually need to switch out of one collection and into another to start working in that collection. I don't believe you can have two collections open simultaneously.

My stock answer for this question is that Team Projects should mirror the lifecycle of you projects. For example, if you have customers and you do projects for customers than I would create a Team Project for each customer project ... Even if it involves the same source code as another project.

For in-house development the lifecycle of a given application is typically "forever" so I'll see them using a Team Project per line-of-business application.

The only reason a shop as small as yours would want to create additional project collections is if you needed that level of isolation. Some reasons include: 1. You have a legal or regulatory reason ro keep source code and work isolated (government, privacy, PCI, etc). 2. You have customers which want their work items and code delivered to them at the end of the project. Some may want the history so it is nice and easy to give them their own project collection instead of having to sort through others' data.

If you need more info, it may help to post what the nature of the projects are.

Each collection requires a separate Build server (and license), so you should consider that in your planning. One Build server, one Collection.