ABCs of a Branching and Merging Strategy


As parallel development is introduced, the level of branching complexity increases. As complexity increases, the amount of effort to manage change within a more complex branching environment increases. This should be an expectation that project management understands and plans. If they do not, ensure you advise them of this fact.

This is the trade-off of going to a parallel development model. While it may enable faster-time-to market, it may also increase the amount of effort and coordination in certain stages of the project and in particular adds merging and testing tasks to the project plan. Keep in mind that merging typically requires retesting to ensure that the code merged is tested appropriately, particularly where logical lines of conflict have to be reconciled.

Another aspect to considering effort is the project management strategy as it relates to the delegation of development work. If specific chunks of work are allocated to specific <--pagebreak-->groups, then less merging and testing is likely to occur. However if the project manager is indiscriminate in the way the work is being doled out then a significant amount of merging may occur increasing the amount of effort and quite possibly 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. 

<--pagebreak-->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. 

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.