Organizing Your Server with Team Project Collections
You can manage your team projects more efficiently by grouping them together and assigning the same resources to them. For example, you can group projects that have similar requirements or objectives, such as all projects that relate to a particular code base. You can then manage that grouping as an autonomous resource with its own user groups, server resources, and maintenance schedule. In Visual Studio Team Foundation Server 2010, you group team projects together in one or more organizational units called team project collections. A team project collection is an organizing structure that you can use to define and control a group of team projects within Team Foundation Server. When you create a collection, you specify the logical and physical resources that team projects within that collection can use. All the artifacts and data that those projects use is stored in the single database of the collection.
Team project collections provide server administrators with the following advantages:
A single database that stores all the data for every project in each collection. Administrators can back up and restore this database independently of other collections.
A scalable method that administrators can use to manage the resources that development efforts require. Administrators can reassign resources to better meet the demands of the projects within a collection.
Team project collections provide project administrators with the following advantages:
A grouping of related projects that can share reports, work items, and process guidance, as well as a code base.
An autonomous code base that can be built, branched, merged, and iterated according to the needs of the projects within the collection. Code dependencies outside the collection can be formally managed.
If you create multiple collections, you can store all databases for them on a single instance of SQL Server, or you can distribute the databases across one or more instances.
The following illustration shows how databases for team project collections are integrated with the logical architecture of Team Foundation Server:
When you install Team Foundation Server, you can create a default collection to contain all team projects, or you can delay creating a collection. For example, you might delay creating your first collection until after you have added a SharePoint Web application that is hosted on a server that is running Microsoft Office SharePoint Server 2007. However, you must create at least one collection before you can create your first team project. All projects must be created within a collection.
If you upgrade Team Foundation Server from an earlier version, a default collection is created, and all existing projects are stored in that collection. After you install or upgrade, you can create more collections to best suit your organizational requirements.
If you create more than one collection, you can better separate the operational needs for one code base or other grouping of projects from the operational needs for another grouping. Because the data for each collection is stored in its own database, you can independently manage many aspects of each collection separately from other collections in your deployment. For example, you can stop and start each collection individually. Therefore, you can schedule maintenance operations for each collection at different times.
Because each collection has its own set of users and permissions, you can help increase your operational security by isolating different code bases in different collections. You can then add users only to the collection that contains the project or projects that pertain to that particular code base.
If you create more than one collection, you increase the complexity of your deployment of Team Foundation Server. You must back up and restore the database for each collection, and other management and maintenance tasks also increase in proportion to the number of collections that you have. For example, you must manage the set of users and permissions for each team project collection individually.
In addition, you should consider the following facts when you decide whether to create multiple collections:
You cannot link work items across collections.
You cannot branch or merge code across collections.
You cannot create queries across collections.
You can perform all of these functions across team projects within the same collection. You should consider consolidating team efforts to projects within a single collection if your development efforts will benefit from the ability to branch and merge code or you must query the status of work items that relate to the same code.
Organize resources for supporting team projects: You can create one or more team project collections to organize and support related development projects.
Add resources to existing team project collections: You can add a SharePoint Web application or a server that is running SQL Server Reporting Services to a team project collection after you create it.
Change the location of a team project collection: You can move a team project collection from one deployment of Team Foundation Server to another.
Reorganize what projects are in a team project collection: You can change the organization of projects in a collection by splitting it and then deleting projects from each collection until both collections have a unique set of projects.
Start or stop a team project collection: You can stop a team project collection to maintain it or to update an underlying component on which Team Foundation Server depends.
Change resources for team projects within a collection: You can change the resources that are available to team projects within a collection, such as the Web application that projects in the collection use. You can also change user permissions and groups at the collection level.
Delete a team project collection: You can increase the resources that are available to other team project collections and simplify your deployment by deleting collections that have no active or viable projects.