Team projects and interdependencies

Question

Hi,

I am quite new to tfs and branching/merging strategies.I am wondering if anyone here could give me some advice on what are best practices in relation to inter dependencies between team projects and specifically common utils in our projects. I have read a few articles including

http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=Explained%20-%20Defining%20Your%20Branching%20and%20Merging%20Strategy

http://prashantbansode.blogspot.com/2007/04/to-branch-or-not-to-branch.html

http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

But none of them seem to cover my problem.

Our structure is somewhat like this where we have 3 projects and a common utility dependency in all the projects and Project C depending on A and B as well as the common utility.

- CommonUtils
- Project A depends on CommonUtils

- Project B depends on CommonUtils
- Project C depends on Project A, Project B, CommonUtils

Group x works on project A
Group y works on project B
Group z works on project C

How can we maintain isolation between the three groups? As each team might be adding to CommonUtils during development should CommonUtils be

a) branched to each of the projects
b) referenced directly on project level
c) referenced by dll where changes would require a new version to be created in the CommonUtils team project

Should Project C contain branches of Project A and B or should it reference the Mains?
Should we use project dependencies or dll dependencies for this scenario?

In TFS should we structure each of the entities CommonUtils, Project A, Project B and Project C as separate Team Projects or should they all be part of the same team project?

As we have some common 3rd party libraries in each of the projects what would be a logical strategy to reference them from each project?

a) Separate lib folder in each of the team projects
b) Use network drive where all libs reside
c) team project called Libraries containing the libs

Thanks in advance.

Regards,
Bangar

Answer 1

Another good source of info you should read is the TFS branching guidance written by the people behind TFS version control, you can find it here http://www.codeplex.com/BranchingGuidance

 

In order to give you any guidance I need to ask you the following questions.

1.       Will project A, B and C be in one release or will it have separate release cycles?

2.       Will there be dependencies between the projects?

3.       Is it required that all projects runs on the same version of 3^rd party controls?

 

Cheers

  Lars

 

Answer 2

I read the branching guidance as well as chapter 6 of the p&p tfsguide

Managing Source Control Dependencies in Visual Studio Team System (http://msdn.microsoft.com/en-us/library/bb668956.aspx)

To answer your questions:

1.
Projects A, B and C will have separate release cycles.

2.
Yes dependencies between the projects are in the form that CommonUtils are used in all of the projects and Project C depends on Project A and B.

3.
It is not required that all projects run the same version of 3rd party controls



So if we look at the structure I mentioned again:

- CommonUtils
- Project A depends on CommonUtils

- Project B depends on CommonUtils
- Project C depends on Project A, Project B, CommonUtils

As is mentioned in the TFSGuide Chapter 6 (link above) they recommend branching CommonUtils into each of the other projects and I presume for Project C the structure would be something like this:

Project C
   Main

Source

Code

Lib

SharedCode

CommonUtils

Project A

Code

Lib

Shared Code

CommonUtils

Project B

Code

Lib

Shared Code

CommonUtils

Projects A and B should be branched into C. What happens to CommonUtils now? In solution for Project C should I reference 3 branches of CommonUtils (they may have changed on each of the branches)? Is that even possible to build?

Should I merge CommonUtils from A and B into Project C/Main/Source/SharedCode/CommonUtils and only reference that CommonUtils project in the solution for Project C?

Does this make any sense?

Thanks for the help.

Answer 3

When each project have separate release cycles you need project isolation. That also implies isolation of the common utilities hence branching is necessary unless you are willing to treat the utilities as a 3^rd party dependency with its own release cycle towards Project A, B and C. The latter poses more problems than it solves so I wouldn’t go that way unless the dependency from Project C to A and B is binary i.e. Project C loads A and B into its address space and therefore CommonUtils are only loaded once.

 

The general idea here is that you have full project isolation to control your release cycles.

 

Project C

Dev

Source

            Code project 1

            Code project 2

            CommonUtils (Branched from $/CommonUtils/Main/Source)

Dependencies

                                                3^rd party libs

                                                Referenced libs from project A and B

                                    TeamBuildTypes

                                                Team build project file for Project C

 

Project C.sln

 

Common Utils

            Main

                        Source

 

Project A

Dev

Source

            Code project 1

            Code project 2

            CommonUtils (Branched from $/CommonUtils/Main/Source)

Dependencies

                                                3^rd party libs

                                    TeamBuildTypes

                                                Team build project file for Project A

 

Project A.sln

Project B

 

The down side to this approach with branching CommonUtils is the promotion path i.e. the number of merges to perform to promote the code from development to stable to production. The path should be structures something like this:

 

CommonUtils->Development->Main/stable->Release

 

This path dictates that any changes coming from any of the other project will have to go through CommonUtils to Dev before it can be accepted into Main, that’s a good thing but it also requires work every time you need to merge and you need to have frequent merge operations on CommonUtils to ensure that you have the latest and greatest bits for your projects. But this is only you who can decide if this is worth the effort J.

 

If you don’t require project isolation on CommonUtils you could use workspace mapping to achieve a kind of sharing. The principals involved are simple you keep the above suggested structure with the exception of branching CommonUtils and use workspace mapping to map the location $/TP/CommonUtils/Main/Source/ to the folder location of $/TP/Project C/Main/Source. Let’s say you have mapped $/TP/Project C to C:\Workspace\TP/Project C, you would then add an additional mapping from $/TP/CommonUtils/Main/Source to C:\Workspace\TP\Project C\Main\Source\CommonUtils. This approach would force you to have a strict workspace structure for all team members but it should be doable.

 

In respect to having multiple team projects or not I would go for one especially if your projects are perceived as one PRODUCT, the benefits of this is the common process model, Area definitions (like CommonUtils) and the ability to assign work items to different teams (within the same team project). Once a work item is created in a given Team project it can’t be moved to another only copied an therefore you lose all history on it if let’s say a Bug is create in team project Project C but is in fact a bug in Project A.

 

I hope you find this useful and I would like to see what you end up choosing.

 

Answer 4

Thank you.
I appreciate your input.

One thing that is not clear is what happens when dependencies are shared: Project A depends on CommonUtils and Project C depends on CommonUtils as well as Project A

Then the structure would be something like this:



Project C

Main

Source

Code

ProjectCsrc

SharedCode

CommonUtils

Code

CommonSrc

ProjectA

Code

ProjectASrc

SharedCode

CommonUtils

Code

CommonSrc

Notice the the two branches of CommonUtils - in both C and A.

Would this even work?

If I branch CommonUtils and ProjectA into ProjectC SharedCode and then reference the branches in the solution file for Project C which CommonUtils would Project A refer to? I can only have one CommonUtils loaded hence both Project C and referenced Project A would have to reference the same CommonUtils right?


Is there a better way to do this? Does this require me to create release binaries for CommonUtils and reference those? Does that make life any easier?

Does using workspace mappings solve this at all?