Freigeben über

Partitioning Mechanisms in TFS

  • Artikel

In our discussions with Customer A this week, we focused for quite a while on the differences between the various work partitioning mechanisms in TFS:  areas, iterations, and source control organization.  At a high level, you can think about them this way:

  • Areas - Useful for logical partitioning of workitems by functionality
  • Iterations - Useful for temporal partitioning (e.g. beta1, beta2, release, servicing)
  • Source code organization - the source control repository's tree structure for partitioning by code modules

Customer A had some great questions about how they might organize their team project and its many sub-projects using areas & iterations and how that relates to the tree hierarchy of their source code. 

The quick answer is: "You decide!"

We suggested building up an area hierarchy based on the major functionality provided by the sub-applications in their large IT project (served by a single Team Project).  Areas are primarily used to organize tasks, workitems, and bugs.  Some teams organize their areas in the same way their department or organization is organized, but I tend to prefer the functionality approach - reorgs happen all the time, and you don't want to have to update the areas for all your bugs every time you get a new VP :)

As for iterations...  These are useful for organizing a project based on time.  For example, major milestones:  iteration 1, iteration 2, beta 1, beta 2, RC (release candidate), RTM, and servicing.

In source control, you might be tempted to mirror the area hierarchy to organize your code.  If you're product is a code library or SDK, this might make sense.  But you probably want to organize more on a structure that makes sense for the way you've modularlized your code.  For example:

    $/OurTeamProject/main
       /GUI
        /BusinessLogicLayer
     /DataAccessLayer
        /CommonCode

Of course, this is just a very simple example.  Depending on the granularity of your team project, you might have one or more layers of subfolders under the TeamProject before you get to actual code for your assemblies/DLLs/exes.

So there's a quick spin on areas vs. iterations vs. source hierarchy.  As we continue through the week with Customer A, I'll continue posting about any points that seem to be applicable at a broad scale.  Of course, if you have any requests, let me know!

cheers,

-Jason

Update 8/28/2006 - Based on comments, I've updated the version control tree structure above to include a "main" branch directly under the team project node.  This is necessary if you're using a branching model and want to branch to folders under the team project.  If you still have questions, let me know and I'll do a follow-up post to explain this better.

Comments

  • Anonymous
    August 22, 2006
    Jason,

    Is source code hierarchy you have presented there is one big piece missing. If folks are going to use branching, they in all probability will not start the hierarchy right under team project root but introduce additional level as in
    $/
     Team Project/
        Ongoing/
           GUI/
           DataAccess/
           BusinessLogic/

    That allows branching to be performed under on project root (as root node itself cannot be branched).

    Overall I think that additional level is rather good starting point in any case and is a general recommendation, because recreating hierarchy is not very healthy activity.

    So at least additional level in the hierarchy is what I would start from, not the outline you have proposed.

    Yours truly,

  • Anonymous
    August 22, 2006
    You are absolutely correct.  I left out that critical layer, which would serve as your main integration pivot point between your sub-branches.  We call our main branch "main" rather than "ongoing", but it's exactly the same idea.  In fact, to additionally help illustrate the difference between the branch hierarchy and the scc folder hierarchy in terms of logistics, you might even stick another "branches" folder in there as a peer of "main".  

    $/TeamProject
      main/
        GUI/
        DataAccessLayer/
        BusinessLogicLayer/
      branches/
        branch1/
          GUI/
          ...
        branch2/
          ...
        etc.
  • Anonymous
    August 28, 2006
    In a private reply to my recent post on TFS Partitioning, someone raised the question of team site partitioning. ...