locked
One team project or multiple ones for a large product? RRS feed

  • Question

  • We have a large product that has a generic core product.  This core product has multiple versions.  The core product is a single Visual Studio solution with many projects in it.   There are multiple client specific implementations of the core product.  Each of these client implementations is a copy of the core product VS solution/projects with customizations.  We currently use ClearCase to manage the code like this:

    core product
       v1
       v2
       v3
    client 1
       v1
       v2
    client 2
       v1
    .........

    client1 v1 has files linked to core product v1, and client1 v2 has files linked to core product v2 etc. 

    For source control purpose, I know it's better to setup one single TFS team project with multiple folders (coreProduct, client1, client2 etc) so we can use branch/merge to do what the ClearCase Linked File function does today (my understanding is branch/merge can only be done within the same TFS team project, right?).

    However, for work item tracking purpose, we really need each client implementation to be in its own team project for access control.  The team for each client implementation is pretty large and one team should not have access to another team's work items.  I can't think of a way to control access to work items based on the same template (so a user can add/edit/query work items for one client but not the others), though I can group the team members into client specific security groups.

    So here's my dilemma, for source control purpose, I need to have one team project, but for work items, I need to have multiple team projects.  Since such one base product with multiple client implementations is a very common structure, I'd like to get some ideas and comments from the folks who have been in similar situations.

     

    Wednesday, February 7, 2007 6:04 PM

Answers

  • Hi,

    Have you looked at the option of creating multiple Area Paths (under one Team Project) and setting appropriate permissions (View/Edit) for these area paths. If not then I think this is something you can evaluate and see whether it will meet your needs.

    You can find more details on creating area paths and configuring permission for area paths at  http://msdn2.microsoft.com/en-us/library/ms181479(VS.80).aspx 

    For instance in your case you can define area paths like

    <Team Project1>\Core Product

    <Team Project 1>\Client1

    <Team Project 1>\Client2

    etc., and you use IterationPath (http://msdn2.microsoft.com/en-us/library/ms181480(VS.80).aspx) for defining different versions (V1, V2,....) for each of these products

    Hope this helps

    Saturday, February 10, 2007 8:01 AM

All replies

  • Hi,

    Have you looked at the option of creating multiple Area Paths (under one Team Project) and setting appropriate permissions (View/Edit) for these area paths. If not then I think this is something you can evaluate and see whether it will meet your needs.

    You can find more details on creating area paths and configuring permission for area paths at  http://msdn2.microsoft.com/en-us/library/ms181479(VS.80).aspx 

    For instance in your case you can define area paths like

    <Team Project1>\Core Product

    <Team Project 1>\Client1

    <Team Project 1>\Client2

    etc., and you use IterationPath (http://msdn2.microsoft.com/en-us/library/ms181480(VS.80).aspx) for defining different versions (V1, V2,....) for each of these products

    Hope this helps

    Saturday, February 10, 2007 8:01 AM
  • Thanks a lot.  That's what I'm looking at.  My current template has a Contributeors group defined that every user belongs to:

    <group name="Contributors" description="">

    -  <permissions>
         <permission name="GENERIC_READ" class="PROJECT" allow="true" />
         <permission name="PUBLISH_TEST_RESULTS" class="PROJECT" allow="true" />
        <permission name="GENERIC_READ" class="CSS_NODE" allow="true" />
        <permission name="WORK_ITEM_READ" class="CSS_NODE" allow="true" />
         <permission name="WORK_ITEM_WRITE" class="CSS_NODE" allow="true" />
     </permissions>
    </group>
     
    I think I'll need add new user groups, e.g. client1_group, etc. and assigne specific Area permissionto each group.  Should the last two CSS_NODE permissions be removed so the Area-specific permission can work? It seems to me that the two entries give everyone default access to all work items and I'd have to apply "Deny" on the new user groups, which I want to avoid.
    Sunday, February 11, 2007 11:38 PM
  • If you have already created team project(s) using this process template you can use "Team Project Settings-->Areas and Iterations..>Security.." on this Team project and remove (or deny) the Edit, View permissions at the root level for Contributors group. Then you can create project specific groups (add Project specific members to these groups) and assign specific area permissions

    Also you can remove these entries (css_node permissions for Contributors group) from the process template if you are planning on creating new Team projects using this template

     

     

    Monday, February 12, 2007 6:27 AM