ABCs of a Branching and Merging Strategy

[article]

the project schedule. Even if no branching is used this latter scenarios (e.g., indiscriminately allocating work) will significantly increase the amount of testing that will be needed, therefore impacting the project schedule.

If there is a need to work on several lines of code at the same time, then 1 line of code may force a level of serial development and mostly likely cause significant testing, therefore impacting the release schedule. This may also cause many developers to work outside of the CM system in order to isolate themselves from others. On the other hand, if there is little need for parallel development, then too many branches may be confusing and causes more effort in merging than is needed.

The balance is to consider the level of complexity and identify several branching options to support the complexity. Then a level of effort can be considered per option to determine what may be acceptable.

Risk to Stability

As the complexity (as described above) of application development increases, so does the risk of negatively impacting stability on the project if it is not managed effectively. At this point, you understand the complexity of the application development in the short-term and long-term and you understand the effort as they relate to the branching options. Now review the branching options and determine how much risk to stability you are willing to accept. Risk to stability may have a direct impact on the project schedule it is important to involve project management in this decision.

A low risk tolerance to impacting project stability suggests that an integration branch should exist to support a stable project branch. While all changes are placed into the integration branch, only those that have passed certain milestone builds and tests should go into the project branch. Also, low risk suggests that if you are working with other sites, then separate site branches should be considered so that each site can be isolated from the local site. But what comes with a low risk tolerance is a potentially higher level of effort. 

A high risk tolerance to impacting project stability does not mean you have to abandon branching, it just means that you will accept the risk associated with having more people work on less branches. For example, a high risk tolerance may allow remote sites to merge directly to the integration branch or even the project branch. Also, this scenario may have developer's private workspaces back directly to the project branch. 

 

The End of the Beginning

Overall, the question is, do you want to control the changes or do you want the changes to control you. By constraining yourself to 1 line of code (working off of the main branch or trunk) or creating too many lines of code can significantly impact the amount of effort involved in branching and merging and the amount of testing that is needed to manage changes. Finding the balance is the key.

To summarize the approach specified in this article for preparing a branching and merging strategy, consider the following steps:

·       Understand the terminology. Either borrow terminology from existing materials or create a consistent branching and merging terminology for your organization, application, or project.

·       Understand the reasons for branching. Ensure they are legitimate and can be explained to others.

·       Determine the complexity of the application development as it relates to branching and merging to help determine the types of branches that may be needed and when merging should occur. Establish several branching options.

·       Assess the levels of effort for the potential branching options.

·       

About the author

Mario  Moreira's picture Mario Moreira

Mario Moreira is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “Adapting Configuration Management for Agile Teams” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “Software Configuration Management Implementation Roadmap.” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at http://cmforagile.blogspot.com/.
 

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!