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
Some claim 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 and 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 (which includes rebuilding and retesting) to the project plan.
Branching and 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 a bug fix to the logon code to the same person who is enhancing the logon code in the new release, then this same person will have the full knowledge of what went into each separate stream of code and can then reduce the time it takes for merging.
In addition, within a project, if the Project Manager assigns all requirements changes that impact reporting to the same person, then this person will not have to contend with merging his reporting changes with another person who is making reporting changes. This could effectively eliminate and certainly reduce merging within a project. When merging is reduced, so is the amount of time that it takes to resolve merging conflicts, rebuild (if appropriate) and retest. Moreover, this reduced time can lead to an earlier project release date, even if it is only a day or two.
The key to understand is that the goal should not be to eliminate parallel development, but to ensure it is minimized to the level of parallel development that is needed and most effective in improving productivity.
Summary
When approaching parallel development, it is important to be well educated in the needs of the development organization and the techniques and strategies of branching and merging. Getting the development group involved including the Product and Project Manager will lead to a better understanding within the project and across projects as it relates to parallel development. Many times, even within a project, let alone across projects, there is a lack of understanding of who is working on what and developers can easily clobber each other’s changes or important functionality can be missing from a release.
What may help your success is to approach parallel development with the goal of: understanding development needs; devising an appropriate branching and merging model; implementing a CM technology that supports the model, and working with Product and Project Manager to reduce the level of parallel development to what is effective for the project.
