VS ALM Rangers Branching Guidance - Ideas for the next release.

  • Article

I think most would agree that the Rangers Team has already done a fantastic job with the Rangers Branching Guidance. This is not meant to be a self-serving comment, since the current branching guidance is the result of the hard work of many others in addition to myself. For the past couple of years I have had the opportunity to answer dozens of questions that have been posted to the Branching Guidance discussions forum. I have also worked with a variety of customers, helping them design and plan effective branching strategies.  Through these efforts, I have come to believe we can make a number of valuable improvement and additions.

The approach taken in Branching Guidance II (2008) was to propose a series of branch plans of increasing complexity (Basic, Standard, Advanced). This approach has been well received as we have gotten considerable positive feedback. However the primary focus of the branch plans in the current guidance has been to help customers understand different options (from simple to complex) with respect to the branching for release and sustained engineering.

Each of the branch plans in the current guidance has just a single development branch. I recommend thinking about branching for development separately from branching for release and sustained engineering. Nevertheless, how teams develop software is sometimes tightly coupled to or influenced by how teams release software. For example, on a Scrum project,  the team needs both a development branch plan and release branch plan that enables Sprint teams to work on multiple features during a Sprint (development), and makes it easy to release only those features that are done at the end of a Sprint.

A branching strategy should make it easy to defer unfinished features to a future Sprint. Even teams that do not practice pure Scrum may have agile or iterative methodologies where completed features are released at the end of each iteration while providing for certain features to started during one iteration but not released until they finished two or three iterations later.

As we contemplate updating the current branching guidance, I propose, taking the existing branching plans (basic, standard, advanced) and describe them as branching plans for release. Then I would propose adding a new set of branching plans for development, such as a basic or single-team development branch plan, feature team development, branching for Sprint development (Scrum), and branching for Iterative development.

As we add more content to the guidance  we should view a complete branching strategy as a combination of branching structure + branching process. To that end I propose having much more information in the guidance describing how to manage branches and merges. Some examples:

  • Why do we recommend daily builds in the Main branch with frequent (daily?) merges from Main to development branches.
  • Why do we recommend not doing a daily merge from a development branch to the Main branch.
  • What are typical quality gates a development branch must pass before being allowed to integrate with other branches. I call this state ready to release or ready to share  or ready to integrate. I think we need to add content to describe what we mean by ready in this context.
  • What are the recommended techniques for integrating two or more parallel development branches once they reach a state of ready to integrate? In the current guidance we take a firm stance against adding an integration layer to the development branch plan. In place of an integration layer, we need to better describe the process for integrating two or more parallel feature teams (sibling branches).
  • Why do we recommend not doing merges (forward integrations) from Main into a Release branch after the release branch is created?
  • What are the benefits, in a branching strategy, of automated testing, especially Build Verification Tests (BVTs) – and how can these can improve code velocity.
  • What other techniques for improving code velocity and code quality during development (such as using Static Code Analysis and Style Cop) should be considered as part of branching guidance/

We should also add more guidance on helping teams understand and manage the complexity of merges

  • Doing more frequent merges from a stable branch (Main)  to less stable branches (Development). Doing merges only at specific milestones from less stable branches to more stable branched.
  • What are merge conflicts and how can they be avoided or made easier to deal with? There are a variety of causes of merge conflicts. Some of these happen at check-in, some happen during a merge. Helping teams gain a fundamental understanding of how merges work and what typical merge conflicts are may help teams improve their velocity.
  • I would like to add a section on third-party merge tools that may help teams deal more effectively with merge conflicts. There are several tools that do a better job presenting a three-way merge dialog, visualizing merge conflicts and making conflict resolution easier.

To summarize I want to improve the guidance in the area of branching process as well branching structure.

These are just some of the ideas that I would like the VS ALM Rangers team to address in the next release of branching guidance. Some may disagree. Some may have more important priorities. I welcome feedback, but more importantly I welcome contributors to this section of the guidance.

Next Steps:

  • I am looking to finalize an outline and gain consensus
  • Drill down and write the content according to the outline
  • We will be firing up a number of parallel efforts soon, so I am looking for contributors to this specific Epics or initiatives.

I welcome any thoughts people have for moving from *a list of volunteer contributors* to *final draft*