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 ToolsThe 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 ManagementConfiguration 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 ModelsIn 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:
Repository-Based ModelsRepository-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:
Ideally, tools that provide both models are best, because both models may be useful on the same project. Managing Parallel DevelopmentOn 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 branchAfter 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 branchIt'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
|