This author is not a storng proponent of the Parallel Development , the fifth design pattern. I feel that it has some fundamental flaws that make managing the quality and consistency of your CIs very difficult. Parallel Development issues from my perspective:
- Introduce errors into your Application at points in the development process (usually later States) where they are difficult to find and fix
- When Merging it is inherently difficult to ascertain the impact of a change on the Application as a whole unless stringent testing occurs along with the new merged versions
Personnel who have made changes off the mainline trunk are not always present when a merge has to occur. Inappropriate personnel (quite often the SCM Administrator) get stuck trying to guess what should be merged or not
Text comparators within SCM tools or IDEs do not do a good job of helping the developer understand the full impact of a change in the Application when merging
- Lack of communication up front in the design process causes developers to execute branching to get around design issues
- Takes more time to complete development due to the added complexity of managing branching and merging
- Introduces a higher level of risk than Single Line Development
Admittedly, there are some legitimate reasons for Parallel Development:
- Need to perform two or more isolated lines of development on the same baseline of code but for different purposes
- A team is working on two or more project releases at the same time
- Working with other remote sites, especially with today’s “follow the sun” development life cycle
- Emergency bug fixes
If you do implement a Parallel Development model it is important to establish a strict branching, merging and approval strategy/policy. This is needed so that all stakeholders in the development process know what the branching and merging rules are and expectations of how the Parallel Development model will impact the development of an application.
Figure 14 shows a Parallel Development implementation that I have seen work well.
This Parallel Development design pattern would be considered simple by many, but I feel it has some key features that make it very reliable, has high quality, and is manageable.
- The branches follow a subset of the mainline branch which incorporates an initial level of quality control
- The branch CIs flow into the Development State of the mainline branch so that all the States will be gone through, thus insuring the high level of quality that all other CIs have
- Since the Branch CIs enter the system in the Development State of the lifecycle they do not impact CI configurations in later States
- There is a dedicated developer who analyzes the branches as they enter the Mainline Branch
The baseline trunk that is indicated in Figure 14 should be periodically refreshed at important points in the development process (version releases, point releases, major new functions) so that the branches are starting off from a recent version of the Application. For those who wish to explore more of the Parallel Development Design Pattern, the following two links will take you to two informative white papers on the topic in CM Crossroads: Streamed Lines: Branching Patterns for Parallel Software Development
ABCs of a Branching and Merging Strategy
Parallel Development requires a sophisticated SCM tool to allow a development team to be successful. Parallel Development also requires both a comprehensive and intuitive user interface as well as a database that can track the various branches and merges effectively. When integrated with a multi-state Design Pattern, we have reached a high level of SCM functionality found in only a few of the SCM