Configuration Management Tools

Controlling change is one of the best practices identified in the RUP. Configuration management tools provide developers with check-in and checkout capabilities for the files under development.

Features Needed in Configuration Management Tools

The most difficult aspect of employing configuration management tools is that it is difficult to achieve a balance between complete control over all changes and ease of performing changes. There is a direct trade-off between these two qualities. It is important that the tool chosen for configuration management provide the flexibility to enable both qualities to be achieved. Without this balance, developers may be impacted and become frustrated, because it is difficult to make routine changes. The following sections discuss important capabilities needed in a configuration management tool.

Workspace Management

Configuration management tools on the market today usually use one of two methods for managing the environment workspace. The first is a copy-based model, and the second is a real-time, repository-based model. Each has its advantages and disadvantages.

Copy-Based Models

In copy-based models, a physical copy of a selected set of files is placed on a local disk on the client's PC. Therefore, all the files needed by each developer are placed locally on their respective PCs. The work performed in a copy-based model is made in isolation from that of other developers, until the developer owning the files on the local disk explicitly indicates that she wants to synchronize her files with the latest contents of the changes made by other developers. This model is very similar to the model used by commonly available configuration management (CM) tools, such as CVS. Copy-based models are preferred in the following situations:

• Developers need absolute top-speed access to files. Because the files in a copy-based model are located directly on the client PC, there is no network overhead for file access.

• Developers need to disconnect from the network, such as when using a laptop. Because a physical copy of the files can be made directly on the PC, developers can disconnect from the network and work on files remotely.

• Network access to the files is either slow or unreliable. In this situation, having a local copy of the files needed is more practical than attempting to access them over an unreliable or slow network.

Repository-Based Models

Repository-based models differ from copy-based models in that usually the files in a repository-based model physically reside in a centralized repository, not on the developer's PC. This is similar to how someone would view files on a file server. Repository-based models are generally preferred over copy-based models because they have the following advantages:

• Developers can have real-time access to updates in the repository. The moment the update is checked in by one developer, it is available to other developers.

• New workspaces that re-create older baselines can be created nearly instantly, because there is no physical copying of files.

• Repository-based workspaces require very little disk space on client PCs, because most of the files accessed reside in the repository on the server.

Ideally, tools that provide both models are best, because both models may be useful on the same project.

Managing Parallel Development

On many projects, many activities happen simultaneously. For example, some developers may be performing maintenance on a previous release, and other developers may be working on creating a new release at the same time. In addition, developers performing these different tasks may need to make changes to the same file or set of files. This process is known as parallel development. It is important that the chosen configuration management tool provides comprehensive capabilities and rich functionality for managing branches and using branches for parallel development.

A series of successive versions of a file is called a branch. When changes must be made in parallel to the same file, the tool should make it possible to isolate the changes on separate branches.

Figure 6-4 shows a single branch with no parallel development involved.

Figure 6-4. A single branch with release labels

All files belong to a main branch, whose version number starts with 0. To facilitate parallel development, a separate branch is created for each developer. This allows each developer to have his own branch on which to perform work. Because each developer has his own branch, they are free to check out and check in files independently (in parallel) from the work being performed on other branches. The labels "Rel 1.0" and "Rel 2.0" are examples of labels documenting the baseline in which those particular versions participate.

Figure 6-5 shows an example of a main branch with parallel branches created for two developers, Bill and Jane. Whenever a branch is created, it starts with an exact copy of the version from the source branch on the source tree. In other words, in Figure 6-5, version 0 on both the Bill and Jane branches is exactly the same as version 0 on the main branch. After that point, subsequent versions on each branch (versions 1 and forward) are modified independently and in parallel. Thus, Bill and Jane can check out and check in on their own branches completely independently without interfering with each other's changes.

Figure 6-5. A main branch with parallel branches for developers

When development reaches a point where the developers have completed making their changes, the changes must be integrated. A special branch called the integration branch is created for this purpose. Files are not checked out and checked in individually on the integration branch. Instead, as each developer is ready, a CM administrator (or someone with that role) merges changes from the source branch (owned by the developer) to the destination branch (called the integration branch). Merges are performed from each individual developer's branch when he indicates he is ready. After merges from all developers are completed, integration testing can begin.

Figure 6-6 illustrates this process. The chosen tool should provide a utility for managing the merging process.

Figure 6-6. Merging the work of individual developers to an integration branch

After all developers have merged their changes to the integration branch, a label can be applied to create a baseline of that release. After testing on this candidate release has successfully completed, it can be merged back to the main branch. Figure 6-7 illustrates this process.

Figure 6-7. Delivering an approved release to the main branch

It's not uncommon that specific fixes or corrections to prior releases need to be made to a baseline without including any other changes other than what is required to correct the problem. The chosen configuration management tool must accommodate this scenario as well. Figure 6-8 shows a branch that was created specifically for making corrections to the Release 1.0 baseline. By using branching in this manner, the original 1.0 baseline is preserved, yet a copy of the 1.0 baseline can be modified and corrections made. At the conclusion of this activity, a label is added to reflect the bug fix (release 1.0a, and subsequently, 1.1).

Figure 6-8. A bug fix branch showing corrections to the previous release

Other Features and Capabilities Needed

• If possible, the chosen configuration management tool should be integrated tightly with the other development environment tools used frequently by the developers. This improves productivity because the developers do not have to move to another interface to perform common commands, such as checking in or checking out files.

• Another useful feature is creating a bill of materials for a release. This is the ability to determine exactly which versions of files were used in a given release.

• The configuration management tool should maintain a complete audit trail of all versions created through checking in of new versions. Versions should be able to be compared to each other to discover the exact changes between one version and another.

• Similar to change request management tools, the behavior of the configuration management tool used should be customizable. This makes it possible to cause the tool to conform to and enforce the configuration management process used by the organization.