Approaching Parallel Development with Branch - Merge Strategies

Many times when managers first consider parallel development, it appears to be a very effective way to manage changes to concurrent streams of development. This is somewhat true if the project uses an SCM technology that allows for stable branching and establishes discreet project and maintenance branches in which developers can modify their code.

However, what is often forgotten is that while branching is a great way to separate code changes, at some point merging will have to occur. In other words, parallel development is meaningless without a branching and merging model to support the development. This brief article hopes to provide guidance for approaching and performing parallel development.

Why Parallel Development
There are claims that parallel development will increase productivity by allowing two or more streams of development to occur at the same time. This is a tempting scenario for Product and Project managers who are always looking for ways to improve their time-to-market goals. Moreover, parallel development may occur within a project or across projects (and often times both).

In many cases, parallel development occurs within a project release context where two or more developers are working on the same piece of code at the same time in different workspaces. In other cases, parallel development occurs across streams of development including the: current project release (2.0), future release (2.1), maintenance or bugfix of past releases (1.0.1), and customer specials or variants (2.0a, 2.0b, etc).

Given the above possibilities for parallel development, most groups end up performing parallel development at one of these levels (within a project or across projects). And finally it is important to understand that parallel development may occur anyway so it is important to learn the concepts of parallel development and what can be done to approach it in a constructive and productive way.

Advice on Approaching Parallel Development
This section will provide guidance when approaching parallel development. Ultimately, it is better to plan for parallel development in advance, then stumble into it after some mistakes have been made (e.g., lost code because developers clobber one another’s code, missing functionality in a new release, etc.).

Understand parallel development and branching & merging
CM professionals will most certainly have requests for parallel development although they may not be called this. Even if there are no requests for it, it may be occurring anyway (amongst two or more developers on a project). Therefore, it is first important to learn the basics of parallel development and branching & merging. This will help in future discussions with Product/Project Managers and key developers on their parallel development needs and it will help in defining processes. Consider reading the following article for more information on this area:

• ABCs of a Branching and Merging Strategy , by Mario E. Moreira

The Implications of parallel development
Once there is a good understanding of the concepts, consider holding a session to discuss parallel development needs with the Product Manager, Project Manager(s), and several lead developers. This will help you identify what may be needed by way of parallel development. For example, ask how much concurrent development may occur within a project and then how many streams of development will occur across projects (current, future, past maintenance, etc.).

Also, ensure that the product members understand that when you branch, a merge may have to occur which requires additional work beyond a merge. Most merge processes include merging, rebuilding (as needed) and retesting prior to checking and promoting the code to the backing (aka, integration) stream. This extra work can be more demanding than initially expected and the Project Manager(s) should consider adding a merging task