Approaching Parallel Development with Branch - Merge Strategies

(which includes rebuilding and retesting) to the project plan.

Branching & merging model 
With both sets of information, design a branching and merging model that will support the needs of the product. Consider documenting the model in a procedure and accompanying graphic. Again, ensure you include all steps involved with branching and merging and specifically that merging includes potentially rebuilding, retesting, prior to checkin and promote. Once you have the model designed, review it with Product and Project Managers and key development staff for consideration and approval. This should also include identifying branch naming conventions. For more on designing a branching and merging model, consider reading these books:

• Software Configuration Management Implementation Roadmap  by Mario E. Moreira, Wiley Publishing, 2004, specifically the “Define the Branch Design” section found in the “Establish an SCM Infrastructure for an Application” chapter.
• Software Configuration Management Patterns, Effective Teamwork, Practical Integration  by Stephen P. Berczuk with Brad Appleton, Addison Wesley Professional, 2002, specifically the ‘Patterns’, ‘Mainline’, ‘Private Workspace’, ‘Active Development Line’, ‘Codeline Policy’, ‘Private Versions’, ‘Release Line’, ‘Release-Prep Code Line’, and ‘Task Branch’ chapters
  

Merging in your workspace
A suggestion when merging is to first merge changes to your workspace. This way, you can resolve any merge conflicts in your workspace before checking in and promoting to your backing (aka, project integration) stream. When you do promote, then it is effectively a trivial merge in that there are no code lines of conflict to reconcile.

This technique can apply whether there is parallel development occurring within a project or across projects. Within a project, if you want to promote code to your project integration (aka, backing) stream and you know there have been some amount of changes already promoted, and then merge from the integration stream to your workspace. Then reconcile differences, rebuild (as appropriate) and retest prior to promoting it to the integration stream.

Across projects, if you know there are important fixes in the maintenance branch that have already gone into the production baseline, then merge those changes into your workspace, reconcile differences, rebuild (as appropriate) and retest prior to promoting it to the latest project integration stream. Below is a graphical example of this technique in action in the ‘across projects’ scenario.

Identify a CM Technology that supports branching and merging
A key component to parallel development is a CM technology that supports robust branching and merging and particularly the branching and merging strategy that has been designed. Many groups or organizations already have a CM technology so consider investigating the robustness of the branching and merging functionality within this tool. However, if you do not have a CM technology yet or the one that exists is not adequate, it is essential that a CM technology is evaluated against the requirements of branching and merging (as well as other CM tool requirements) and the best CM technology for the group or organization is selected.

Product and Project Manager’s role in parallel development  
Many times, the parallel development function is thought of as either the responsibility of CM professionals or developer, since CM folks establish this infrastructure (e.g., CM tool and branching and merging model) and developers typically carry out the merging tasks. However, the Product Manager and Project Managers play a key role. The way they assign the development tasks to respective development staff may reduce the amount of concurrent development amongst developers on specific pieces of code within a project or across projects, and therefore reduce the potential amount of merging or merging time that may occur.

For example, across projects, if a Product Manager assigns the work for