Why not develop in Main?

Sep 11, 2011 at 2:15 PM

Of all the advice and branching designs I have studied, I hear "Do not checkin directly to main. Only checkin to the Dev branch. Than RI back to Main. Main must remain stable."

Why? Why can't I develop directly in Main?  After all, the simplest plan most people start with is no branch at all. They just checkin to the one and only source base.

As soon as we want to support simultaneous bug fixes and future development, of course, we need branches. I have ready the Ranger's guidance and identify the Single Team Branching model as the recommended approach.  It has a Main (stable and resembling production) and a Dev branch. Hot fixes happen in Main and are deployed to production from there. So this is the one plan that recommends checking in changes directly to main. But they are hot fixes, and thus limited in scope and frequency.  Future development happens in a Dev branch.

But I have also envisioned an alternative. And I want opinions as to whether it is better or worse in any cases than the other plans. I am envisioning a simple branch plan with Main and Release. Every time you release software, you FI to Release. You develop and checkin future release work to Main.

Can anyone see any weaknesses in this approach for a simple scenario like the one the "Single Team Branching" model was designed for? That is, our requirement is simply to support production with hot fixes while future development proceeds without delay. If we ever decide to start additional future releases in parallel, then we will create a dev branch for each off of main, and have a picture that resembles the Basic Branch Plan from the Branching Guidance except that we develop V.Next in Main and V.Next + 1 in Dev.

 

Developer
Sep 11, 2011 at 2:45 PM

I would refer you to the Basic Branching Plan. With the Branching Plan, Main should still be reserved for stabilizing vNext. Hot fix changes to vCurrent (Production) should be done in the Release Branch. The Rangers do not support or recommend combining Main and Development. Each of the branches in the various branching models serves a purpose and exists to help customers avoid problems that are commonly seen. Main does not *resemble production (vCurrent)* as much as it is used to *stabilize* the next release (vNext). As you contemplate more complex development branching plans, Main should also be used to facilitate integration between the varios development branches (which are usually full children of Main).
In the Rangers Guidance, Hot fixes are not checked into Main. Rather they are checked into a Release branch established for that purpose. Once tested, they can be merged (RI) into Main and then merged (FI) into the Development branch(es).

The Single Team Branching Model scenario is likely to be eliminated or rewritten in the next release of the guidance. Where there are differences between the Single Team Branching in the Scenarios and the Branch Plans in the Main Guidance document, please follow the Main guidance.

As for developing vNext in Main and vNext  +1 one in Dev - I would strongly recommend against this approach, based on my experience working with many customers who encounter challenges with this type of branching structure.

Regards,
Bill Heys
VS ALM Ranger

 

 

Sep 11, 2011 at 10:29 PM

Thanks for your advice. It is very clear. And I will gladly recommend it to my team. To be precise, I will recommend we follow a variation on the basic plan that you outlined in your May 23, 2011 post on how to handle overlapping parallel releases. http://blogs.msdn.com/b/billheys/archive/2011/05/23/isolating-and-integrating-parallel-feature-teams-working-on-separate-overlapping-releases.aspx. We can choose the simpler of the two plans: the one labeled "Monthly Releases - Parallel Dev Teams" since we do not need an additional integration layer for the Dev teams.

However, I still don't understand the "WHY" of your advice. Can you (or anyone else) give me just one example of a scenario where we would regret using Main for development?  I am asking partly so I can learn the underlying reasoning. And I am also asking because my coworkers may reject the advice to add another branch for stabilization unless they understand the risks. And I lack the experience to articulate those risks. We understandably want the simplest plan that will serve our needs. 

Developer
Sep 12, 2011 at 12:54 AM

I will try to explain why we recommend starting with a stable Main branch and branching from Main for Development. When you begin developing a brand new product (or application), you start with a Main branch. From Main you branch to create a Development branch. At some point you may reach a milestone in development where you are ready to begin extensive QA testing of features that are *done* in development. At this point, we recomend labeling the Devleopment branch with this milestone, and merging (RI) Development to Main. The code in Main should be built every day and validated with automated Build Verification Tests (BVTs). Periodically the code in Main can be deployed to a QA environment for extensive testing. In the meantime, development might continue in the Development branch. Every day, developers should check their code into the Development branch. We recommend doing Continuous Integration (CI) in the development branch. CI implies triggering a build when code is checked into the development branch, and running automated tests as part of the build. Every day, therefore developers are continuosly integrating their changes with those made by other developers on their team. However, new features may not be *done* at the end of any given day. For this reason, the development branch is less stable (or complete) than the Main branch. When you get to the point that the code is feature complete and relatively stable in development, merge (RI) the code from development into Main for further testing by QA. Hopefully, at the end of an iteration (or Sprint if you are doing Scrum), all of the features being developed during the iteration will be done and can be merged to Main for stabilization prior to Release. But what if one feature is not complete at the end of the Sprint. At the end of a Sprint unfinished features, still in development, should not be merged into Main for stabilization and release. At any point in time, Main is dedicated to stabilizing completed features prior to release, while development may be ongoing for the current or next iteration (Sprint).

Another way of explaining the separation of Main from Development might be to suggest that you identify the need for multiple feature teams working in parallel. These teams may be working on different feature for the current iteration (or Sprint or Release), or they may be working on separate iterations or releases (vNext and vNext+1). Some of my customers have situations where features are released when they are complete. Let's suggest you have individuals or teams working in parallel on four features. Each team might have their own feature branch. This means there would be four feature branches representing the four parallel feature teams. Whichever team finishes a feature next, merges their changes (RI) from their feature branch into the Main branch. The Main branch could be used to stabilize this feature while the feature team continues working on another feature. When the second team completes a feature, the second feature branch is merged (RI) into Main. Main can now be used to stabilize the first two completed features. The second team can now begin working on a new feature. At any point in time, Each of the feature (development) branches is used for ongoing development of a feature. Main, however is being used for stabilization of only completed features. If you have a feature team checking code into the Main branch there will be a comingling of completed features with features in various stages of completion. It will be impossible to stabilize Main since it contains code for unfinished features that are not ready for stabilization.

The rangers guidance recommends not using Main for ongoing development so as to prevent unfinished features from being comingled with finished features that require stabilization. The pattern, in this scenario, is that whether you have one development branch or several feature team branches, all development branches are full children of Main. I see no benefit to changing the basic pattern (for example having three of four feature team branches as children of Main while having the fourth feature team checking into Main). Our recommendation is to have ALL feature team branches as full children of Main. Whether it is ten feature teams, four feature teams, or one feature team working on vNext development, the pattern is the same. The Feature Team works in a development branch that is a full child of Main.  Each of the feature team branches should be siblings of all of the other feature team branches. You should NOT have one feature team branch being the parent to all of the other feature team branches.

You may not know, in some projects, which feature team will complete a feature first. So how can you decide, in your scenario, which team should check changes into Main. What if they never finish their feature by the end of an iteration. How do you stabilize only the completed features while continuing development of any unfinished features. Having ALL development happen in DEVELOPMENT branches with no development changes being checked into Main prevents the nightmare that would result otherwise.

In out branching plans, Main is ALWAYS the parent to ALL of the development branch(es) and ALL of the release branch(es). Our basic branch plan has three branches. Development (for vNext work in process), Main for stabilizing vNext features that are ready for QA, and Release (or Production) for vCurrent and post-production hot fixes

Note - in this response, I am NOT suggesting adding an integration layer between Main and the Development branch(es). When a feature team is ready to share their feature with other teams, they can merge their changes (RI) into Main where they can be picked up by the other team(s) on the next merge (FI) from Main to Development.

So now I would ask you this question: Given the *why* as explained in this response, what benefit do you see from not *always* having development checkins happen in a development branch and not the Main branch.?

Regards,
Bill Heys
VS ALM Ranger

Sep 12, 2011 at 1:09 AM

The only reason we favored developing in main was to reduce the number of development branches by 1, with a corresponding reduction in merge activity. But now that I understand better what it means to use Main as a place to stabilize the next release, I can see the wisdom in the recommendations.  We can certainly make Main an unstable place. But then it will be really messy if we switch releases around (like by changing scope in one so that it gets done sooner or later than expected).

Thanks for taking the time to provide me with such a thoughtful and detailed response. I found it very educational.