New to TFS 2010, Team Project Collections (TPCs) provide an additional layer of project organization/abstraction above the Team Project level (see the MSDN article, “Organizing Your Server with Project Collections”)

I’ve been asked numerous times over the past couple of months about the intention of project collections, their flexibility and limitations.  Below are simply my educated thoughts on the subject.  Please do your due diligence before deciding how you wish (or wish not) to implement project collections in your environment.

You can use collections to more tightly couple related projects, break up the administrative process, or to dramatically increase scale.  But the primary design goal behind introducing project collections is around isolation (of code, projects, or groups within an organization) in a way that provides all the benefits of TFS, scoped to a defined level within a single instance of TFS.  You’re effectively partitioning TFS.

If you have ever used TFS 2005 or 2008, think of it this way.  A project collection effectively compartmentalizes all the capabilities you’ve grown to love in a single TFS 2005/2008 instance:

I won’t go into how you create/edit/delete project collections.  Just know that you can.  (BTW – for those of you upgrading from an earlier version of TFS, your existing projects will go into a single default project collection (by default, it’s named “Default Collection”.  Original, right?)

Consider this (over-simplified) example.  I have 4 projects in my server, currently in a single (“default”) collection:

Say Project A and Project B are used by “Division A” in my company, and Agile1 and Sample Win App are used by “Division B”.  Project A and Project B share some code and leverage the same user base.  The assets in each division’s projects are in no way related to the other.  Consequently, I’d love to take advantage of project collections and separate our divisions’ stuff.  A more practical implementation of project collections might look like this:

I build out my collections using the TFS Administration Console to look like this:

Once that’s done, I can ultimately end up with such a structure that my desired projects are contained in their respective organization’s collection:

Division A’s stuff:

Division B’s stuff:

Now each division’s stuff is effectively compartmentalized.  No shared process templates, no shared user base, and no shared database (which means one division’s screw-up won’t affect another division’s work).

Okay, so I lied a little – I earlier said I wouldn’t go into detail about how to CRUD collections.  But I will mention one thing here, which will add context to the above scenario.  In the above, I had a single collection that I effectively wanted to split into two collections (i.e. go from “Default Collection” to “Division A” and “Division B”).  This is surprisingly easy to do (more complicated than drag & drop, but not ridiculous either).  The documentation for splitting a collection lists 15 main steps to accomplish this, but basically what you’re doing is cloning a collection and then deleting what you don’t want.

See?  I told you it would be a simple example.  But if you expand this to think of a TFS environment with 100 projects (instead of my puny four), you get the point.

This all sounds pretty cool, right?  It. Is. Very. Cool.  Project collections can be used for various purposes in your TFS deployment (consolidating related development efforts, scaling the SQL backend, mapping TFS hierarchy to organization hierarchy, etc.).  However, with flexibility comes complexity.  If you had fun sitting around a conference table debating how to structure your TFS 2005/2008 project hierarchy (perhaps consulting our branching guidance document or patterns & practices?), project collections add a new element to consider for 2010.  Below I’ve outlined some of the main considerations for you and your team to think about before taking advantage of project collections in TFS 2010.

For Systems Administrators:  Pros & Cons

Pros

• Flexibility to to backup/restore collections individually.  This can reduce downtime as restoring one collection will not impact users of other collections.
• Since each collection is contained in its own database, these databases can be moved around a SQL infrastructure to increase scale and load balancing.
• Could help consolidate IT resources.  If your organization currently leverages several TFS instances simply to isolate environments between departments, collections can allow the same TFS instance to be used while still providing this isolation.

Cons

• Again, with flexibility comes complexity.  Since project collections use their own databases, each one must be backed up (and restored) individually.  Also, other admin tasks such as permissions and build controller configuration grow proportionately as additional collections are created.
• Users and permissions need to be administered separately for each project collection (this may also be a project admin consideration).
• There are more databases to restore in the event a full disaster recovery is needed.

For Project Administrators:  Pros & Cons

Pros

• Organizational hierarchy.  If your organization has multiple divisions/departments, you can break up your TFS project structure to reflect that organizational view.  This makes it much easier for users to identify (or constrain via permissions) which projects belong to their department.
• Projects grouped in the same project collection can leverage similar reports (“dashboards”) work item types, etc.  They can can also inherit source code from other grouped projects.

Cons

• In Visual Studio, you can only connect to one collection at a time.  While it’s relatively trivial to simply connect to a different collection, you can’t view team projects in Team Explorer that reside in different project collections.
• Relationship-specific operations you enjoy across team projects cannot span project collections.  This means that there are several things you cannot do across collection boundaries, such as:

• Branch/merge source code (you can do this cross-project, but not cross-collection)
• Query work items (i.e. you can’t build a query that will show you all bugs across multiple collections)
• Link items (i.e. you can’t link a changeset in one collection to a task in another collection)
• Process templates are customized and applied at the project collection level, not the TFS server level

What does it boil down to?

It’s really about your need for isolation.  Do you ideally want to isolate by application/system, organization, or something else?  Do you foresee a need to share code, work items, or other assets across projects?  It’s a fun little decision tree:

So that’s it!  The devil is always hiding in the details, so do your own research and use your own discretion when deciding how to adopt project collections into your TFS deployment.  I anticipate more guidance on this topic to come out as TFS 2010 installations propagate throughout the world.

For more resources and practical guidance on using Team Foundation Server, see the TFS team’s blog on MSDN.

I hope this helps you somewhat!  And thanks for reading!