20.3 Parallel Development

Parallel development occurs when people have to work on the same configuration item at the same timewhen branches have to be formed from one item (the trunk), and the results are merged. The need for parallel development may be caused by time pressure, shift work, or distribution of expertise.

Example

A company has to produce a large requirement specification, which includes both a graphical user interface and communication protocols. Different experts will have to work on different parts of the requirement specification at the same time. The requirement specification is therefore divided during this work and merged into the final document near the end of the activity. Figure 20-5 illustrates this process.

Figure 20-5. Parallel Development and Merge

If the experts have worked on separate parts, like a chapter each, the merge is probably not difficult. It may, however, be complicated indeed, especially if time pressure is the driving force and a number of people are working in more or less the same places in the items. Fortunately, some tools support the merging of configuration items.

Planning Considerations

Parallel development is a planning decision and is therefore the responsibility of the project manager or development manager. Consider carefully whether parallel configuration items should be placed under configuration management or the parallel development should take place outside the configuration management system, in the production environments.

What needs to be considered is whether the intermediate versionsR S 2A1 through R S 2A3 and R S 2B1 through R S 2B2 in the exampleshould be made public and whether it's necessary to know their individual history, or whether it's only of interest to know the history from R S 1 directly to R S 2. In the latter case, development is not parallel from a configuration management point of view, but the actual parallel development must of course be catered to in planning, and the merge must be performed before the final result is placed under configuration management.

Parallel development under configuration management should be limited to an absolute minimum. To avoid it, it might be advisable to make changes to the design and split an item into more independent items. It might also be worth considering the XP practice of pair programming and let two developers do two changes together, instead of splitting the work between them.

This section is about " genuine " parallel development, where branches are placed under configuration management. However, some of the discussions are also valid if parallel development is done outside configuration management. Where parallel development can't be avoided, frequent merges should be planned, to make the branches as few and as short as possible.

Configuration Management Considerations

Where parallel development can't be avoided parallel individual configuration items must be considered. Parallel development may work its way through to deliveries, so parallel deliveries will have to be produced. If something is really parallel development, however, it must be made clear whether the result is a merger into a single configuration item or if it's variants.

Identification

Identification should reflect parallel development, so that metadata indicates whether an item is a branch in parallel development and, if so, which item it originates from and possibly which item the branching will end up in. Figure 20-6 shows good and bad examples of version designations for parallel development.

Figure 20-6. Naming Conventions in Parallel Development

An extra data element may be necessary in the metadata to register the trunk in a branching, but most often this can be solved by the name alone. Tracing must branch off and merge with the items themselves . It's important to know at all times which functionality is maintained wherewhich part of the trunk each of the branches is responsible for. Two branches should not share responsibility for any part of the trunk.

Storage

Configuration items that are branches must be stored individually, on an equal footing with all other items. Branches that exist as independent configuration items are stored as described in the Multivariants section, above.

Change Control

Change control must be done with extra care in parallel development. The configuration control board(s) must have access to branching information, to determine whether an item is a branch and, if so, which item is the trunk and what other branches exist. Based on this information and relevant trace information the board(s) may decide if an event is to enter into a branch or maybe wait until the merge has taken place.

Status Reporting

Status reporting must take any possible parallel development into consideration. It should be possible to produce a report that identifies all branches from a trunk and to identify who has received which branches between merges. Status and history for each branch should be presentable independently of other branches from the trunk. Even after the merge, it's important to be able to get information about each of the branches.

Tool Considerations

Several configuration management tools offer a variety of comparison and merge facilities. However, most tools are not able to perform a reliable merge of items with conflicting differences. This could be changes to the same piece of source code in two different ways (for two different, but valid, reasons) from the same trunk. In these cases, the board responsible for the trunk and the result must step in and decide how such a merge is to take place, if at all. This may be done with tool support, though it requires a final human judgment.