locked
Tips for organizing Team Projects? RRS feed

  • Question

  • All, we're about a week away from our first stab at setting up TFS. A small team went to two days of TFS deep-dive taught by Steve Borg, and got a great overview of how the system works and some info on limitations and workarounds. I need some advice on the part that worries me the most, the way Team Projects are organized.

    Here's my situation: I work in the IT dept. of a 3,000-person company. We have a lot of COTS apps with cutomization and configuration, and a moderate amount of app development -- web apps, reports, middleware, etc., mostly for internal use. We're in a single geographic location, have a single data center, and about 20 developers and an ever-changing cast of consultants who need access to source control. We have a Project Management Office (PMO) and an app maintenance group, and about 150+ applications to support, each with one or many projects. We're currently using VSS 6.0 :-(

    Projects may get initiated through the PMO, worked on and eventually transferred to the Maint. group once they go live. Or, if small enough, they may originate in the Maint. group, either as brand-new work or as enhancements to existing systems.

    Steve explained that ALL TFS Team Projects must hang off the root: $/Project1, $/Project2, etc. And, there's a limit of ~500 Agile projects on a server. We could easily have 500+ projects, if they all hang off the root.

     In VSS, I can create subprojects, so my repository root can be fairly clean, and all the real changing items are a couple levels deep. E.g. in VSS I can have

    Code Snippet

    $/PMO/Financial Systems/FinProject1

    $/PMO/Property Management Systems/PMSProj1

    $/Maint/Intranet/InetProj1

    $/Maint/Middleware/Messaging/IntProject1

    $/Maint/Middleware/ETL/ETLProj1

     

    But the root just looks like

    Code Snippet

    $/PMO

    $/Maint

     

    From what I can tell, in TFS, all these projects must hang off the root, either like

    Code Snippet

    FinProject1

    PMSProj1

    InetProj1

    IntProj1

    ETLProj1

     

    or

     

    Code Snippet

    $/PMO_Financial Systems_FinProject1

    $/PMO_Property Management Systems_PMSProj1

    $/Maint_Intranet_InetProj1

    $/Maint_Middleware_Messaging_IntProject1

    $/Maint_Middleware_ETL_ETLProj1

     

    That causes me some pain: We have LOTS of projects, and not much consistency in naming conventions. So it could be very hard for people to locate the project they should work on. Grouping by the dept that owns the project, and by functional categories below that, makes it pretty easy to zero in on the items of interest. And we'd never get near the 500-project limit if we could group them.

    Our team has been kicking around ideas to deal with this. One is to go ahead and make the owning depts. the top-level "Team Projects", and the actual development artifacts as sub-sub-folders within that, just like the VSS example above. But from what I understand, ALL projects under that root TP must share the same Methodology.

    What other limitations does this structure imply? How do people in corporate IT environments like mine deal with this? Any tips appreciated!

     - Val

    Thursday, April 5, 2007 7:29 PM

Answers

  • hello

    you can check the best practices for how to structure you projects in VSTS. they are on codeplex under the following link


    Explained: Structuring Your Solutions and Projects in Source Control with Team Foundation Server

    http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=Explained%20-%20Structuring%20Your%20Solutions%20and%20Projects%20in%20Source%20Control%20with%20Team%20Foundation%20Server&referringTitle=View%20More


    How To: Step Through Creating Your Source Tree in Team Foundation Server 2005

    http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=How%20To%3a%20Step%20Through%20Creating%20Your%20Source%20Tree%20in%20Team%20Foundation%20Server%202005&referringTitle=View%20More


    regards
    zzmsdn
    Tuesday, April 10, 2007 1:19 PM
  • Just today I saw on Brian Harry's blog that they posted a new article on CodePlex that addresses this more specifically:

    http://blogs.msdn.com/bharry/archive/2007/04/30/team-proejct-and-branching-guidance.aspx

     

    The direct link to the article is

    http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Guidance%20for%20Structuring%20Team%20Projects

     

    On a quick read, this seems like the most specific breakdown I've yet seen on making these structural decisions.  I still need to read it in depth and try to absorb it, but it looks like it's got the info I need to make a decision.

     

    Enjoy!

     

    - Val

     

     

    Monday, April 30, 2007 11:44 PM

All replies

  • hello

    you can check the best practices for how to structure you projects in VSTS. they are on codeplex under the following link


    Explained: Structuring Your Solutions and Projects in Source Control with Team Foundation Server

    http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=Explained%20-%20Structuring%20Your%20Solutions%20and%20Projects%20in%20Source%20Control%20with%20Team%20Foundation%20Server&referringTitle=View%20More


    How To: Step Through Creating Your Source Tree in Team Foundation Server 2005

    http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=How%20To%3a%20Step%20Through%20Creating%20Your%20Source%20Tree%20in%20Team%20Foundation%20Server%202005&referringTitle=View%20More


    regards
    zzmsdn
    Tuesday, April 10, 2007 1:19 PM
  • Thanks for the links. They help a bit, but pretty much cover the ground I already knew. The examples are entirely generic, so I still don't understand how to apply this to my organizational structure. The best part in the link is the discussion of where to locate unit tests, because they at least detail the pros and cons of each approach.

     

    It sort of looks like the linked doc suggests I should make each app we implement or support a top-level project, but then I'm stuck with no grouping structures, so people have to hunt thru an essentially flat list of projects, rather than only navigate among e.g. reporting projects, or property management systems, etc. On the other hand, if I put the apps themselves a level or two below the top-level Team Project, then the suggestion for a 'main' folder right under the root doesn't work -- that would branch ALL the apps. I guess I could put the mainline and branches a couple levels below the root, like 

     

    $/OwningDept/App1/main

    $/OwningDept/App2/main

    etc.

     

    But, I don't want to guess -- I'd lke some concrete suggestions and discussion of tradeoffs. Surely I'm not the only person who works in an IT org and needs to group multiple, loosely-related development efforts?

    Tuesday, April 10, 2007 9:45 PM
  • Val,

     

    Have you seen the TFS Branching Guidance page?  http://www.codeplex.com/BranchingGuidance

     

    It may provide some of what you are looking for with respect to branching strategies.

     

    -Matt

    Friday, April 13, 2007 5:32 PM
    Moderator
  • Val,

     

    I think you are confusing the idea of projects in in VSS and Team Projects in TFS- they are not a 1 to 1 correlation. This is where the purpose for areas come into play.

    I'm not certain that just PMO and Maintenance are appropriate Team Projects- it would take more information and discovery in regards to shared code, process, release cycles etc. All these things need to be taken into account to determine team projetcs but I can assure you that it won't be 1 Team Project per VSS Project.

     

    How your source tree looks and how your areas look may be similar in your case. You'd have a few team projects then top level areas for each of the projects and areas further down the tree for additional projects and additional functional areas such as UI, Testing etc.

     

    Team projects are meant to be large with areas providing further granularity.

     

    Does that help. Feel free to png me if this seems like I am pointing you in the correct direction and you need some additional help, or even more importantly if what I am saying maks no sense.

     

    Saturday, April 14, 2007 5:02 PM
  • All,
    thanks for the feedback, and sorry for not replying sooner -- I was out of town on an emergency for a few days.

    @Matt,

    I read about branching, but that's a level below my area of concern. The docs even talk about it, on this tantalizing but frustrating page:

    http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Step1%20%u2013%20Deciding%20on%20a%20Team%20Project%20structure

    There, they make the distinction and say that guidance on Team Project setup is "to be released shortly". I sure hope whoever is working on it can address corporate examples like mine -- it's not a rare use case.

    @Michael,
    Yes, I understand that VSS and TFS projects are different -- I'm trying to understand how to *map* the concepts.

    I can sort of see how the Areas concept can come into play -- but that's at the task level, not directly at the artifact level. The whole point is that under my organizational units I have codebases that don't share anything except ownership.

    In my maintenance dept, the organizational breakdown looks something like this:

    Code Snippet

    Maint
    |- Corporate systems
      |- HR system (COTS app)
      |- Records Mgmt (COTS)
      |- Timekeeping sys 1 (COTS)
      |- Timekeeping sys 2 (COTS)
      |- Production change control (custom)
      |- IT portfolio mgmt (COTS)
      |- GIS systems (COTS, custom)
      |- Reports (COTS, custom)

     

    |- CRM systems
      |- Sales system (COTS)
      |- Intranet (custom, multiple sub-apps)
      |- Sales extranet (custom)
      |- Reports (COTS, custom) 
     
    |- Finance & Operations Systems
      |- Property mgmt for division 1 (COTS)
      |- Property mgmt for division 2, 3 (COTS)
      |- Business intelligence (COTS)
      |- Job cost systems (COTS, custom)
      |- Accounting systems (COTS, custom)
      |- Reports (COTS, custom)

     
    There's virtually no code sharing between applications within a group, or across groups. Each app has code, configurations or customizations we should have under source control. The development and release processes vary by app, not by owning group. So within one group, e.g. the CRM group, the artifacts and processes for the Sales system are completely different than the Intranet. These factors would lead me to put each app I listed above at the top level. But we have 150+ such apps, and with no consistent naming convention, that's not a very usable list.

    I was hoping that, similar to VSS (and CVS, SVN, etc.), I could create top-level groupings in TFS from a *source control* point of view (not just from the work-item point of view, i.e. Tasks and Areas). These grouping don't have to be along our current organizational areas -- in fact, probably shouldn't be, as the structure can change -- but could group systems with similar processes. I'm just looking for a way to group things in a way that makes it easy to know where to find them, but still has a reasonable level of isolation so that different process styles and requirements can be accommodated.

    http://msdn2.microsoft.com/en-us/library/ms242894(VS.80).aspx suggests a combination of Team Projects and Areas and Iterations:

    Is the structure imposed by an external group?
    Your organization may already have a standard structure.... or some other factor outside the software development life cycle. Set the areas and iterations hierarchy for the team project to match the required structure.

    Is the team creating a product?
    If the central focus of the future work is creating a stand-alone product with a clear identity, you can organize the source code, iterations, and areas by the product features. Each new product should be a separate team project.

    This most closely matches my situation -- each of the apps above is, or can be thought of as, a distinct product. So, it looks to me like my best option is just to make each app a top-level Team Project; nothing I've read or heard so far tells me otherwise. Which sucks, cuz a big, flat, unsorted root level is not fun, and I've spent many years working to get stuff off the root and into deeper hierarchies. But I guess it will have to do.

    Again, thanks for the input -- I do appreciate it; the more points of view I get, the more I start to zero in on the solution. If any of you wants to take a stab at organizing the list I wrote above, I'd be happy to see it! But, no pressure -- we'll have a TFS dev box up in a day or two and the best way to learn is practice, practice, rip out everything and start over again and practice ;-)

    Regards,

    Val

     

     

     

    Wednesday, April 18, 2007 9:45 PM
  • I'm running into the same problem as you.  I can't seem to find a way to structurally set my projects up in a Parent/Child relationship.  The only thing I can think of is Create a Top Level Team Project, and create folders underneath it for each sub project.  I don't think this is the greatest idea since it may break some functionality.  Any ideas yet?
    Monday, April 30, 2007 10:08 PM
  • Just today I saw on Brian Harry's blog that they posted a new article on CodePlex that addresses this more specifically:

    http://blogs.msdn.com/bharry/archive/2007/04/30/team-proejct-and-branching-guidance.aspx

     

    The direct link to the article is

    http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Guidance%20for%20Structuring%20Team%20Projects

     

    On a quick read, this seems like the most specific breakdown I've yet seen on making these structural decisions.  I still need to read it in depth and try to absorb it, but it looks like it's got the info I need to make a decision.

     

    Enjoy!

     

    - Val

     

     

    Monday, April 30, 2007 11:44 PM
  • Let me know what you come up with.  we can spread some ideas around once we know a bit more..

     

    thanks.

    Wednesday, May 2, 2007 6:40 PM
  • I've read it, but don't understand clearly:

     

    Please advise on my situation:

     

    I have mutliple lines of businessess and want a top level parent project for each.  Underneath each line of business, there will be multiple projects.  My structure looks like this in its simplest form:

     

     

     LOB A

     - Project 1

     - Project 2

     - Project 3

     LOB B

     - Project A

    - Project B

     

    How do I structure this in TFS?  Do I create a team project for each LOB, and then create just folders for each project?

     

     

    Thursday, May 3, 2007 7:47 PM
  • That should work fine.  For Project 1/2/3/etc, reread the section

    "Providing Substructure Within a Team Project"

    Thursday, May 3, 2007 8:12 PM
    Moderator
  • i wonder if this will cause some functionality (reports, work items, documents, builds) to not work correctly since projects will be encased in folders, rather than at the top team project level.  Are these functions project specific to top team projects only?  Can they be used with the projects at a folder level structure and can it be limited to just those projects?
    Thursday, May 3, 2007 10:11 PM
  • As explained in the whitepaper, the main axes along which you structure work items should be Areas and Iterations.  Work items barely relate to source control folders.  You can link work items to source control changesets & files, but that's neither here nor there.  The only issue that's tangentially related is how to track a work item across branches.  If you make heavy use of branching then I'd add "found in branch" and "fixed in branch" fields to your bug types.

    Most out-of-the-box reports are scoped to the top of a team project.  It's easy to drill into specific folders.

    Documents and builds have no relationship to source control folders at all.  They have their own hierarchies.

    Please let us know if any of this isn't clear, so we can improve our guidance.
    Friday, May 4, 2007 1:37 AM
    Moderator
  • Thanks for your advice.  It would help greatly if you had a pictorial representation of the structure I'm trying to achieve in TFS.... or just confirm this statement.

     

    When trying to acheive a structured project tree, with a top level parent and child level sub projects, do the following:

     

    1.  Create a team project.  Ex:  Group Tech

    2.  Create source control folders for each project under the Group Tech site. 

     

    TFS Server

          GROUP TECH

          - Project A

          - Project B

          GROUP ACCOUNTING

          - Project A

          - Project B

    Friday, May 4, 2007 7:12 PM
  • That sounds fine.  Our team projects are much, much more complicated and they work great for us.  We make heavy use of nested folders and heavy use of branches, so actual code is stored quite deep in the tree.  For example, the version control sprocs live in $/orcas/pu/tsadt/vset/scm/sourcecontrol/services/sql.  More info:

    http://blogs.msdn.com/bharry/archive/2005/11/13/492258.aspx

    http://blogs.msdn.com/bharry/archive/2005/11/12/492198.aspx

     

    I would make sure you create a top-level "main" folder at minimum.  This will make branching much easier -- all you have to do is branch "main", not each top-level folder.  In our system it works like this:

     

    team project -- branch container -- branch name -- top-level folder -- subfolders

    $/orcas -- /PU -- /tsadt -- /vset -- /scm/sourcecontrol/services/sql

     

    This roughly corresponds to hierarchies in the other parts of TFS:

    Work Item Area: Orcas\Lifecycle Tools\Source Control\TFS SCC\Commands

    Documents: n/a (we use sharepoint sub-portals, which are not supported in the Documents view in Team Explorer)

    Sharepoint: http://<server>/Orcas/vsts/tfs/vc platform/qa [my main portal since I'm on the QA team]

    Team Builds: we don't really use Team Build yet

     

    (excuse my poor attempt at making a table in the reply box.  also, all of the above is from memory, so it may not be exactly right...which is probably a good thing when it comes to internal details Smile )

    Friday, May 4, 2007 9:51 PM
    Moderator
  • I was planning on my structure to look like this.  Project A would represent the MAIN folder you are referring to.  This is ok?  We're not the point to utilize branching and merging yet, but I want to make sure we have a working structure so it can be used in the future.  Right now, i want the ability for developers to checkin/checkout code and integrate Visual Studio with this product.

     

    Top Team Project

     - Project A

       - Source (contains source code)

       - Database (contains database stored proc, scripts, etc)

    Monday, May 7, 2007 2:53 PM
  • In your setup, when you create a new branch, it will only contain Project A rather than branching the whole codebase.  That's fine, so long as Project A and Project B (et al) don't have any dependencies on each other. 

    Anytime two projects share dependencies, I like to see them inside the same branch.  In other words, you'd want to have a level of folders like "main" between the Projects and the Team project root -- even if the folks working on A and B never work together.  Branching is cheap, so branching higher in the tree is usually better.

    Like I said, if they are completely independent (at both build-time and run-time) then your way is fine. 
    Monday, May 7, 2007 5:10 PM
    Moderator
  • There may be times that Projects within the same Team Project can be "shared" to utlilize the same code.  Other times, projects within Team Projects can be shared with other projects within other  team projects.  This compliates things eh?

     

    Let me get this straight, this is what you are suggesting in order to share code b/w Project A and B?

     

    Team Project

       MAIN Folder

       - Project A

         - Source

         - Database

       - Project B

         - Source

         - Database

     

    How do you handle code sharing between projects A and B at the different Team Projects level? 

    Team Project A

     - Main Folder

      - Project A

    Team Project B

     - Main Folder

       - Project B

     

    Monday, May 7, 2007 7:45 PM
  • Yes, that's what I'm suggesting.  When interdependent projects are in the same branch, it makes sharing much easier: you can add project references directly and be assured that the relative paths will ALWAYS stay the same no matter how future branches are laid out.

    When projects are not in the same branch, you have a choice of either "sharing" them into each other manually via branching & merging, or adding project references like above.  Code sharing between team projects is a special case of this.

    http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=Explained%3a%20Managing%20Source%20Control%20Dependencies%20in%20Visual%20Studio%20Team%20System
    http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=How%20should%20I%20manage%20source%20code%20that%20is%20shared%20across%20multiple%20projects&referringTitle=Source%20Control%20Questions%20and%20Answers
    http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=Avoid%20Workspace%20Mapping%20to%20Support%20Cross-Project%20Dependencies

    Like the guide says, references are usually preferred.  The problem is maintaining relative paths during future branching.  For instance, if you create a new branch of B underneath $/Team Project B/FeatureBranches/FeatureB-1/ProjectB then your references from A -> B will break because B is now one level deeper.  You can avoid this with careful planning or by adding more intelligence to your build & deployment scripts, but it's extra work.


    Monday, May 7, 2007 8:32 PM
    Moderator