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
For Project Administrators: Pros & Cons
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!
Thanks for the article, project collections look useful however what would be most useful is hierarchical team projects. Is there any reason why this has been completely overlooked in TFS and any idea of if and when they may be implemented? Thanks.
Nice article, thanks for clarification.