deciding team project granularity
On an internal mailing list, a customer question came up for how to set up their team projects. There have been previous discussions about Team Project granularity in the past, but Doug Neumann gave a great response that I wanted to repost here:
In this case, I’d
encourage this customer to look beyond his source control needs at his broader
collaboration needs from TFS. He needs to also consider the work items he’ll be
using to manage his applications, his reporting needs, as well as the structure
of his org that will be using TFS (is he working alone?). We typically advocate
customers creating team projects at a course rather than fine-grained level and
it’s not uncommon for multiple different applications to be managed under a
single team project allowing them to easily report across the applications, move
bugs between applications, etc.
That being said, if
he’s really only focused on source control and truly wants to manage his
applications in different team projects, he needs to figure out where to put the
shared code elements. I usually advise people to put them in version control
under the team project where they’d like bugs to be filed and whose members
logically “own” that code. Alternatively, he could also create a 3rd
team project for managing the shared code. For including the shared code in the
builds of the 2 web apps, he can either branch that code into the other team
projects or use relative pathing to reference it from the location where he
places it. Branching provides a level of isolation equivalent to sharing plus
pinning in VSS that he may not wish for.
