none
Organization of Team Collections / Sharing Common Code

    Question

  • We are setting up a Team Foundation server and looking for the best practices in using it.  We have developers at different locations that write applications that are specific to their business unit, however, we have some developers that write common applications for multiple business units. Currently there are over 100 solutions across the business units that we would like to move into TFS and looking for the best practices in the following:

    1) What is the best way of organizing the code across the different business units / locations so we do not end up with 100's of team projects in one collection?  Would a team collection per location make sense?

    2) What is the best way to share the common framework components across all applications, including the specialized businesses units? We have a common logging, exception handling, and authentication routine that can be used by all.  Currently we are just placing the assembly file (dll) in a LIB file on each solution that needs to use it, checking it into source control, and pointing the reference to that.  We also are using Ajax and have implemented that in the same manner.

    Saturday, April 28, 2012 3:23 AM

Answers

  • Hi,

    1. I'll split the solutions per business unit because it is more logical and the developer thats is working on multiple solutions doesn't have to remember the location of the solutions; he has to know onnly the business unit.

    2. The framework should in one collection and every time you release a new version the other business units should be notified to update their references.


    Daniel

    Saturday, April 28, 2012 7:18 AM
  • The Project Collections and Team Projects can be viewed as isolated containers, althought with different characteristics.  A Team Project Collection is, from an operation viewpoint, fully isolated from each other.   You can't share anything between TPC's.   Team Projects can share more, code, link to work items, builds - but they also represent individual work flows, and can be fully secured individually.

    In your case I would equal a Business Unit with a Team Project, a solution within that with a Team, and keep everything in the same Team Project Collection.  This is the way we have organized our stuff (>100 team projects, >100 developers, clients/business units as a Team Project.  This is also the way the Visual Studio ALM Rangers are now organizing their stuff, see http://blogs.msdn.com/b/willy-peter_schaub/archive/2012/04/28/alm-rangers-switching-to-single-tpc-tp-and-multiple-teams-model.aspx for some nice thoughts on this.

    Your way of sharing the common components works nice, having them in a lib folder under each solution.  The question is then how to distribute them, so that they are easily placed there, and further, that you can easily update them and also know which are updated to which version.  We use a special build to handle subsystems like this, which places the result back in a Deploy folder in the library team project.  Then we branch from that to the lib folder (you have to turn off the branch visualization - that is, convert it afterwards to Folder, so that this does not interfere with your ordinary branching, as the source control only allow hierarchical branching, and not networked branching. The branch is still a branch however, just dont have the glossy interface).  Updates can then be handled using merges.  I have a blogpost from some time ago about this strategy http://geekswithblogs.net/terje/archive/2008/11/02/article-on-subsystem-branching.aspx , it is option 3 that would be appropriate and most like yours.  Also see Jakob's blog about how to implement this strategy http://geekswithblogs.net/jakob/archive/2009/03/05/implementing-dependency-replication-with-tfs-team-build.aspx .

    Another option that could used is to set up your own NuGet repository and use that to distribute them.   Your library build would then push the binaries to the nuget repository and each client would pick from there using the Nuget manager.


    Terje Sandstrom [MVP]


    Saturday, April 28, 2012 10:07 PM

All replies

  • Hi,

    1. I'll split the solutions per business unit because it is more logical and the developer thats is working on multiple solutions doesn't have to remember the location of the solutions; he has to know onnly the business unit.

    2. The framework should in one collection and every time you release a new version the other business units should be notified to update their references.


    Daniel

    Saturday, April 28, 2012 7:18 AM
  • The Project Collections and Team Projects can be viewed as isolated containers, althought with different characteristics.  A Team Project Collection is, from an operation viewpoint, fully isolated from each other.   You can't share anything between TPC's.   Team Projects can share more, code, link to work items, builds - but they also represent individual work flows, and can be fully secured individually.

    In your case I would equal a Business Unit with a Team Project, a solution within that with a Team, and keep everything in the same Team Project Collection.  This is the way we have organized our stuff (>100 team projects, >100 developers, clients/business units as a Team Project.  This is also the way the Visual Studio ALM Rangers are now organizing their stuff, see http://blogs.msdn.com/b/willy-peter_schaub/archive/2012/04/28/alm-rangers-switching-to-single-tpc-tp-and-multiple-teams-model.aspx for some nice thoughts on this.

    Your way of sharing the common components works nice, having them in a lib folder under each solution.  The question is then how to distribute them, so that they are easily placed there, and further, that you can easily update them and also know which are updated to which version.  We use a special build to handle subsystems like this, which places the result back in a Deploy folder in the library team project.  Then we branch from that to the lib folder (you have to turn off the branch visualization - that is, convert it afterwards to Folder, so that this does not interfere with your ordinary branching, as the source control only allow hierarchical branching, and not networked branching. The branch is still a branch however, just dont have the glossy interface).  Updates can then be handled using merges.  I have a blogpost from some time ago about this strategy http://geekswithblogs.net/terje/archive/2008/11/02/article-on-subsystem-branching.aspx , it is option 3 that would be appropriate and most like yours.  Also see Jakob's blog about how to implement this strategy http://geekswithblogs.net/jakob/archive/2009/03/05/implementing-dependency-replication-with-tfs-team-build.aspx .

    Another option that could used is to set up your own NuGet repository and use that to distribute them.   Your library build would then push the binaries to the nuget repository and each client would pick from there using the Nuget manager.


    Terje Sandstrom [MVP]


    Saturday, April 28, 2012 10:07 PM