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

  • 發行項

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*

Comments

  • Anonymous
    June 30, 2011
    Bill, I think you have good ideas for the next release of Branching Guidance. For example, what I really like is the separation of development and release branch plans. I think this is a great way to think about the problem and it should definitely be elucidated more. However, from my point of view something should do one thing extremely well (which the Branching Guidance 1-3 did) instead of trying to mix in a load of somewhat related but only introductorily described topics.Currently the guidance is very generic. Although it is illustrated with TFS, the branch plans can be used with any other VCS as well. The reason is the following: it concentrates on process, not tooling. Now if you start to mix in a section on different merge tools and the like I'm afraid the guidance could lose the status as independent best practice document.Therefore I'm not entirely sure if you should really have that section about merge tools. There are plenty of comparisons of those on the web, do we really need yet another one? In my opinion if you absolutely like to provide something in that area you should at least do it in a separate document.
  • Anonymous
    June 30, 2011
    Thanks for your feedback. I appreciate your perspective. As we begin to drill into the details for the next release of Branching Guidance, many topics will likely become separate sections or likely whitepapers. There are several reasons why I am thinking this way. Perhaps most importantly is the need to be more agile in publishing updates. We are working now on Shared Code and Dependency Management. When it is done and reviewed, I want to publish it sooner rather than wait for all work to be completed on the Main document. Merge tools will likely fall into the category of whitepaper for the reasons you suggest. With respect to Merge tools, I primarily want to make TFS users aware of the possibility of using third-party merge tools to make the merge experience easier and less painful.Thanks for your positive comments about the usefulness of the guidance and suggestions for improvements.Bill
  • Anonymous
    July 03, 2011
    Sounds good -- thanks for your answer!
  • Anonymous
    September 10, 2011
    I totally support your idea. Explaining "Why" all these rules is very informative. It will reveal the underlying principles that you are using and enable us to be more creative. It will share the knowledge.  In my experience, when you ask question like "Why do you have rule X?" then you often get answers like "Because if you do not, and you encounter Scenario A, then you will be sorry because Y."  This enriches the document from merely prescriptive guidance to patterns and even reveals principles.Please encourage your colleagues to capture your and their knowledge in this way so we get a deeper understanding.