Some development tasks take a long time to implement, and intermediate steps are potentially disruptive to an Active Development Line (5). This pattern describes how to reconcile long-term tasks with an active development line.

Note

How can your team make multiple, long-term, overlapping changes to a codeline without compromising its consistency and integrity?

You usually want to use the version control system as a mechanism to keep the entire team up to date on what everyone is doing. Under normal circumstances, you will check in changes frequently. Some development tasks should not be integrated into the mainline to share with the rest of the team until they are complete. For example, you may be making a major change to an interface, and you need to be sure it works before you publish it to the team.

When you are doing parallel development without controlling the interaction between everyone's concurrent changes, you can end up with wasted effort and rework. Most of the time, you want to use the version control system as your communications mechanism. You want to share your work with everyone as soon as you think it is ready because frequent integration is a good way to improve global stability. You also want to put your changes into version control as soon as is reasonable to ensure that you have traceability and recoverability. Also, on a practical note, development systems often do not have the same backup and recovery infrastructure around them as the disk drives that contain the version control software.

Some changes would destabilize the active codeline if you checked them in. For example, a major refactoring can't easily be done in stages, yet you don't want to wait a week before checking in the complete set of changes. Also, because your version control system is a good mechanism for communicating changes to other developers who are working on the same task, you need a place to check your code in to. The alternatives, which include sharing files and other mechanisms that bypass the version control system, can easily cause you to be out of synchronization with each other, even if your communication is good, which is often not the case because we are distracted. Figure 19-1 illustrates this concept.

Figure 19-1. Some tasks are for the future.

Another example of a situation where a small group of developers is working on a task that can cause conflict is this: You are approaching a product release, but a small part of your development team is working on a new feature for a subsequent release. You want this subset of your team to share code changes by using some sort of version control system, but the changes cannot go into the active development line because they are not for this release. If only a small part of the team is working on these changes, the overhead of creating a release line might be too great, because everyone is doing work on the release line, and the mainline should remain in sync with it. With some tools, the only reliable way to synchronize both lines is to check code in to both places. Figure 19-2 illustrates this.

Figure 19-2. Creating a release line too early is troublesome.

A small team of developers working on a future task can have a more lax codeline policy for keeping their work synchronized with the active mainline because they can communicate among themselves more efficiently than the larger team can.

You need a way to allow a team of developers to work on a task that is parallel to the mainline for a short time, while keeping all the benefits of the version control tools.

Note

Fork off a separate branch for each activity that has significant changes for a codeline.

A branch is a mechanism for reducing risk. You can use a task branch as “a mechanism for physically isolating riskier development ventures from the code base” (Vance 1998). Once the activity is complete and all its file changes have been tested, check in files on the activity branch. When the task is complete, merge with the mainline. Michael Bays describes the scenario for a task branch (though not calling it by that name).

You need to be sure that all the code that has changed on the mainline since the time you started your branch still works with yours. Merge the activity branch into the appropriate codeline (as a single transaction). Otherwise, notify the appropriate codeline owner that the change is complete and ready to be merged, and provide the codeline owner with any other necessary information for finding, merging, and testing the change task.

If your version control system supports “lazy branching,” where your branch inherits all the code from the mainline unless it changed on the branch, you can use a task branch when you have to isolate a small amount of “future work” from the mainline. Figure 19-3 shows this structure.

Figure 19-3. Task branch

Task branches are especially useful when you have multiple people sharing work that needs to be integrated together. For this reason, you can also use a task branch for integration before releasing a change to the active development line. You can integrate a number of changes into the task branch and then merge the task branch back into the active development line when the changes pass your tests.

It is important to integrate changes from the active development line into the task branch frequently. You want the final integration of the task branch with the active codeline to go as smoothly as possible.