This project has moved. For the latest updates, please go here.

Can Main be a child of another branch

Sep 7, 2010 at 2:17 PM
Edited Sep 7, 2010 at 2:18 PM


The branching guide tells that "Main" should be created 1st and branched to "Development" and "Release".

But in the project I am working with the branches were created in the order

1) Development.

2) Development -> Main

3) Main -> Production


The question are:
1) Does order matter and I need to recreate branches using the order bellow

1st Main

2d Main -> Development
3rd Main -> Production

 
2) What issues will I have if I use wrong order of creation branches

Developer
Sep 7, 2010 at 2:56 PM

Alex,

As you note, our guidance suggests the following basic branch structure. Starting with MAIN.

MAIN
    DEVELOPMENT
    PRODUCTION (Release)

Technically the order of creation of branches *may* not matter a great deal. There may be confusion when start to add complexity on the Development side of the branch structure. For example, if you wanted three parallel development branches (e.g. feature team isolation), the guidance suggests the following structure. Note, that with the basic branch plan the branch structure is only two-levels deep. The Development branches AND the Production branches are full-children of MAIN.

MAIN
    DEVELOPMENT (DevTeam01)
    DEVTEAM02
    PRODUCTION (Release)

Note: By following the guidance, MAIN is the parent of all development branches. Each of the Feature Team branches are full children of MAIN (and siblings of each other).  It is easier and more straightforward  to add complexity to the Development side when Main is the *starting* point.

On the other hand when you start with Development, you now have a three-level branch hierarchy (Release is a full child of Main which, in turn, is a full-child of Development):

DEVELOPMENT
    MAIN
        RELEASE

Adding complexity (for example parallel development teams) results in the following:

DEVELOPMENT (DevTeam01)
    MAIN
        DEVTEAM02
        PRODUCTION (Release)

I think this structure begins to be confusing. For example one Development branch is the parent of MAIN. Others are children of MAIN.

Regards,
Bill Heys
VS ALM Ranger

 

 

Sep 7, 2010 at 9:09 PM

Wheys, thank you for detailed description but it is still not clear why it won't work If I branch

Devt 1-> Main

Main -> Production

Main -> Dev 2

When Dev 2 is finished it will be merged to the Main and from the Main to Dev 1.

Developer
Sep 7, 2010 at 11:30 PM

Alex,

To be clear, I did not say it *won't* work. I simply said it would be confusing as you add complexity to the development side of the branching structure.

If you adhere to the other aspects of the guidance, which is to set quality gates that must be passed before any development branch merges to MAIN, then it probably does not matter a great deal whether you merge from parent (Devt1) to child (Main), which is forward integration. Or from child (Devt 2) to parent (Main), which is reverse integration. I think it is confusing, but I don't see any reason why it *won't* work.

The goal is to isolate development teams from each other (which you are doing with Devt 1 and Devt 2. And as well to isolate development from the Main branch which should be as stable as possible. If you keep these goals in mind it should *work*.

Regards,

Bill Heys
VS ALM Ranger

Sep 8, 2010 at 6:03 AM

Bill,

Thanks, explicit and clear )

Last questions, they are not strongly connected to the previous post.

1) Can you advice where I can find good algorithm description how branching system works in TFS from technical/developer point of view.

2)  If I have the structure of branches as bellow and I decide to remove DEVELOPMENT that is the root branch. Will deleting of root branch have the influence on merging between MAIN and PRODUCTION?

DEVELOPMENT

     MAIN

           PRODUCTION

 

 

Developer
Sep 8, 2010 at 2:05 PM

Alex,

You should be able to remove (delete) the Development branch without affecting the merge relationship between Main and Production. You need to make sure that if there are any changes in the Development branch that you either merge them to Main first, before deleting Devleopment, or accept that you will likely lose these changes.

As for an algorithm description of how branching works in TFS, I am not sure how to answer that question. TFS is a tool and branching uses the tool to manage and isolate changes in your software. There is no black and white (right vs wrong) way to do branching. There are best practice recommendations (such as having Main be the parent of Devlopment branches rather than the other way around - see earlier discussion).

I would like to note, that our branching guidance recommends creating branches and doing merges at various milestones in the development process. Each organization will likely have a different set of milestones based on their specific software development process. I am not sure how to translate process into an algorithm. Maybe you have an example.

Using the basic branch plan as an example. You would typically have your project source code stabilized in the Main branch before beginning development for the next release. Assuming you do not yet have a development branch, you would create this branch PRIOR to beginning development. As you proceed with development you might do daily builds on the Main branch, and frequent (daily) merges *from* Main *to* Development. But you would NOT typically merge *from* Development *to* Main until such time as the code in Development passes quality gates and is either deemed ready to share with other development teams OR is ready to release to production. At this point you would merge from Development to Main. Now you would stabilize the code prior to release in Main. Once the code in Main passes quality gates and is ready to release, you would create the Production branch. Note that you would NOT typically merge from Main to Production after creating this branch (for various reasons outlined in our guidance).

Regards,
Bill Heys
VS ALM Ranger

Sep 8, 2010 at 3:42 PM

Bill, thanks for you help and sharp answers )