locked
TFS project(s) for SOA RRS feed

  • Question

  • Hi there!

    I am about to engage as Technical Project Manager in a larger service oriented development project where we want to embrace SOA concepts such as autonomy to minimize dependencies between our applications/services. TFS 2010 will be used for both source code and project management, but also likely for continuous integration, testing with the new MS Test Manager tool, and a common project portal for documentation and discussions.

    My thoughts and questions now are regarding how this should best be setup in TFS. We will have multiple applications and services, but it's still only one development project when it comes to planning, reporting, etc. From the start, it will only be one team, but after the base architecture is complete, we want to scale up and have multiple teams work on different components of the SOA solution.

    My initial idea is to only have one TFS project so that the areas, iterations and work items for all components will be in the same repository. But as we want autonomous components, we would use one VS solution per application/service which can then contain multiple VS projects for the different internal layers.

    The structure of the source control tree would then be similar to:

    (Root)
      Service1
        Main
          Service1.Business
          Service1.Data
          Service1.Service
        Releases
          ...
      Service2
        Main
          Service2.Business
          Service2.Something
          Service2.Else
        Releases
          ...

    Does this seem like a good approach or are there some best practices that we should consider following? Also I would appreciate feedback on important implications of this decision.

    Thank you in advance! This is interesting stuff! :)

    // Peter

    Wednesday, December 8, 2010 10:26 AM

Answers

All replies

  • Hi Peter,

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
     
    Thank you for your understanding and support.


    Best regards,
    Cathy


    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg @ microsoft.com
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, December 9, 2010 7:28 AM
    Moderator
  • Thanks Cathy - I look forward to feedback!

    // Peter

    Friday, December 10, 2010 10:07 AM
  • Hi,

     

    This is more of a advisory services type of question, which is beyond the scope of a forum post.  I can offer you some general guidance on using source control and formulating a plan for organizing your cod in Team Foundation Server.

     

    These are all excellent, in-depth discussions of using source control in TFS:

    Patterns and Practices Guide:

    http://tfsguide.codeplex.com/

     

    Branching and Merging Guidance:

    http://msdn.microsoft.com/en-us/library/ms181423(v=VS.100).aspx

     

    TFS 2010 Branching Guide:

    http://tfsbranchingguideiii.codeplex.com/

     

    The walkthroughs are more general examples that may prove useful:

    Team Foundation Version Control Walkthroughs

    http://msdn.microsoft.com/en-us/library/ms181279(v=VS.90).aspx

     

    Thanks!


    bill boyce
    Thursday, December 16, 2010 5:00 PM
    Moderator
  • Hi Peter,

    Your SOA project structure question is very well formed and merits further discussion. Over the last couple months I have read all of the above Guides and walkthroughs at least twice searching to solve basically the same question. The problem is none provide specific guidance for SOA pattern where several separate services (each their own "project" or "solution") will be combined in different ways to deliver different "products".

    Your original proposed approach sounds good.

    Solution files: I agree a single solution file for each service is important when the service will need patches and newer releases separate from other services.

    Versioning should be at the service level rather than product (or assembly) level. All files within a service should share the same version. (This also supports having separate solution files even when overall product is composed of several services.)

    TFS Team Project(s): Having many services and products (front ends) in the same Team Project is fine, especially if many follow the same release cadence, share same work item templates, require common reporting, and/or share similar group membership for contributor/reader/administrator securty. There are drawbacks to single TFS Project (including build definition sprawl management, Deeper iteration paths and area paths, and more described in other posts) but if starting fresh then I agree it's best to keep everyone on the same team (or related teams) working in the same Team Project.
       If you already have separate Team Projects established then the issue of consolidation becomes much more difficult. In general I'd suggest keeping existing Team Projects and establish *bridge* branches to a consuming Team Projects if that project needs to update/extend the service source code to support its release. See this Branching Guide discussion for a much longer wandering exploration.

    Branch structure:
    I'm still working through the details for branching structure. A separate main for each service (as outlined in original post) should work, but there are some pros and cons to not having a common root branch.
    New (immature) services (v1 through v3+) often require new functionality or fixes to meet needs of the next client product (unless architecture and execution of the service was perfect in v1). You will be shipping the Product2 out of one branch and Service1_v2 out of the Service1 Main->Release branch. Multiply by 5 or 10 services and release management becomes critical to ensure branches are used properly. Two products needing changes to the same shared Service1 solution may need their own Service1 feature branches until they can stabilize and merge to the Service's main branch. Release management must be clear to require shipping every Service1 release through the Service1 Main branch (to a Release branch) to ensure each release is cumulative rather than releasing variations of the same service.

    Source code that is shared by many services can pose some similar challenges. For example, a new customized Enterprise Library block, logging library, or custom automation framework project may be both used in and extended for use by multiple services at the same time - especially in early stages of development for the shared project.

    • If all services need the same changes (or all work done by the same team) then work directly in the Shared project development branch and dependent projects can use daily or tested "known good" builds.
    • If a Shared project needs major rework for one service that might destabilize the other services then make a branch off SharedProject's main to stabilize this change in isolation.
      Optional *bridge* branch: If you have separate TFS Team Projects you can create the new SharedProject Dev branch in a folder under the $Service1 Team Project (next to $Service1/main or "$Service1/Dev/SharedProject-Service1") even though the parent Main branch is in the $SharedProject Team Project. I refer to this as a *bridge* branch because it's parent is in an unconnected Team Project yet the development or feature branch is located conveniently adjacent to the related Service source for consistent development and administration.

    You posted back in Mid-December. I'm curious how your branching structure is comming along and what you've learned so far (good or bad), especially separate main branches vs. having a common root Main branch for services. If my expanations above sound good, bad, or backward please let me know. I'd rather be corrected than continue along a harder path.

    Thanks! -Zephan


    Thanks! -Zephan
    • Edited by Zephan Sunday, February 27, 2011 1:08 AM bullets, clarify isolated vs. common root Main.
    Sunday, February 27, 2011 1:03 AM