Question

I will be managing a migration/update of TFS 2010 to 2012. I'm taking the opportunity to re-organize the structure of our repository.

We are a very large organizations, with a number of divisions. We have many unrelated software applications for each division.

The current structure is a single collection, under which each division has its own Team Project. Every application is saved in a folder under the Team Project to which is belongs.

/DefaultCollection
 /MediaTeamProject
   /MediaWebsite
   /MediaMobileApp
   /MediaCRM
 /Transport
   /TransportSchedulingApp
   /TransportGPSApp
   /TransportWebsite

TFS has been used for source control up until now, but I want to start leveraging its ALM capabilities. My thought was during this migration, I would create a collection for every division, and every solution would have its own Team Project:

/MediaCollection
 /MediaWebsiteTeamProject
 /MediaMoobileAppTeamProject
 /MediaCRMTeamProject
/TransportCollection
 /TransportSchedulingAppTeamProject
 /TransportGPSAppTeamProject
 /TransportWebsiteTeamProject

These software applications are unrelated to each other. My thought is that once I have isolated each software application, I will be able to leverage Team Web Access within our development teams.

Is this structure correct, or am I missing the boat? I ask, as in a previous question, someone mentioned our existing structure was fine, and that I should be using "Teams" (Migrate TFS folder into Team Project)

Microsoft indicates in its documentation: "Logically (or conceptually), a team project is a single infrastructure that encompasses all of the separate tools and elements used in the life cycle of the development of a software application." ref: http://msdn.microsoft.com/en-us/library/ms181234(v=vs.90).aspx

It seems to describe a 1:1 relationship between a software application and a Team Project.

Given every software application is unrelated to any other application, and we want to use ALM, should I be isolating every app into its own Team Project, or should I be doing something else?

No correct solution

OTHER TIPS

If the projects are unrelated it's a good strategy. Whatever you chose, the most important challenge is to understand the implications, mainly:

With Team Project Collections you get:

  • Physical and logical isolation: each collection stored in a different database. This allows maintaining each collection without affecting the others collections. Physical isolation is best for consultancy\outsourcing development scenarios.
  • Better scalability.
  • Each collection will require its own servers and hardware (build controller, test controller, SharePoint portals, etc.)
  • No sharing of code and work items between collections.

With single Team Project Collection:

  • Simpler data model, means simpler maintainability, less storage requirements and easier backups. Upgrades will be easier as well.
  • No physical isolation means some users may see other projects data. However providing support should be easier as the admin team will have follow only one set of rules.
  • Less system and hardware requirements.
  • Allows sharing code and work items.

Bottom line, for increased security and isolation scenarios, choose the multiple Team Project Collections option. Otherwise stick with the simplicity of a single collection.

You point out that the projects are unrelated, but if the developers that work on these projects work on more than one project the overhead of creating one team project per application could be more difficult to manage as each has its own set of permissions and must be managed as completely separate entities. So grouping solutions where possible in the same TFF project could help.

Creating multiple collections will help where recovery is concerned as the risk of catastrophic failure is reduced assuming that reasonable practices are used to distribute and backup the databases.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top