TFS Project Collection layout - suggestions and good practices for multiple teams

Question

Consider a new deployment of Team Foundation Server 2010, with the first use cases being Version Control.

The teams using TFS for Version Control are:

• application development - web applications, SharePoint, db scripts, etc. primarily through Visual Studio
• integration - text files (XML and JavaScript) for an integration engine.
• data warehouse - VS database projects, SSIS packages

Each team typically doesn't have projects relating to each other, and work independently. All projects are internal, and each team has a different set of customers.

The first suggestion is to have a Collection layout as such:

* Applications
* Sharepoint
* Integration
* DataWarehouse

How would you structure a TFS 2010 given these conditions?

Are there any practices or suggestions that would you recommend for these teams in terms of collection structure?

Answer 1

Can collections have collections? If so, I'd suggest a team bases collection. Then each team can have their own child structure as they see fit. It also gives you a nice seperation between teams, giving you flexability in security, stability, etc.

Answer 2

I'll answer my own question here with how I laid it out in this environment with many distinct teams.

For any other developers taking on the TFS admin role, I'd again throw out the suggestion to divide your TFS Collections where the projects won't have any cross-over between teams. This could be however you define it - customers, separate teams.

This helps to allow teams to see & contribute to projects that they're concerned with.

Create new or leverage existing AD security groups for the purpose of granting read/write to each appropriate Group in the Collection. Allow/deny permissions to each Group for the Collections as they're needed.

Answer 3

Steve Lange has a very good posting about this topic ("Thoughts on TFS Project Collections"), click here