|
|
After you organize the project's components, determine your strategy for creating baselines of those components. The baseline strategy must define the following:
A project baseline
When to create baselines
How to name baselines
The set of promotion levels
How to test baselines
In your role as integrator, you are responsible for telling developers which baselines to use when they join the project and when they rebase their development streams. You could keep track of a list of baselines, one for each component. However, a more efficient practice is to use a composite baseline to represent the project baseline. A composite baseline selects baselines from other components.
For example, in Figure 13, Project A uses a composite baseline, PABL, to select baselines in the GUI and Admin components. Project B also uses a composite baseline, PBBL. Baselines that are selected by a composite baseline are referred to as members.
After you create a composite baseline to represent the project baseline, the next time you invoke the make baseline operation on the component that contains the project baseline, UCM performs the operation recursively. If a component that contributes to the composite baseline has changed since its latest baseline, UCM creates a new baseline in that component. For example, assume that developers made changes to files in the GUI component after the integrator created the BL1 baseline. The next time the integrator makes a new project baseline, UCM creates a new baseline in the GUI component that incorporates the changed files, and the new project baseline selects the new GUI baseline.
A composite baseline can select other composite baselines. For example, if your system is so large that it consists of multiple projects, you may want to use a composite baseline to represent the system baseline. In Figure 13, SystemBL is a composite baseline that selects the PABL and PBBL baselines of Project A and Project B, respectively.
In addition to using a composite baseline to represent the project, you can use multiple composite baselines within the same project. When working with multiple composite baselines, you can encounter situations where two composite baselines select different baselines of the same component. When this happens, you need to resolve the conflict by choosing one of the member baselines. To avoid these conflicts, we recommend that you choose a simple baseline design, rather than one that uses a complex hierarchy of composite baselines. See Resolving Baseline Conflicts for details about baseline conflicts.
Like all baselines, a composite baseline must belong to a component. However, that component does not need to contain any of its own elements. For example, in Figure 13, the System_Comp, ProjA_Comp, and ProjB_Comp components consist only of their composite baselines. When you create a component to be used solely for housing a composite baseline, you can specify an option that directs UCM to make the component without creating a root directory in a VOB. Such a component can never contain its own elements.
Figure 13 Using a System-Level Composite Baseline
At the beginning of a project, you must identify the baseline or baselines that represent the starting point for new development. As work on the project progresses, you need to create new baselines periodically.
If your project represents a new version of an existing project, you probably want to start work from the latest recommended baselines of the existing project's components. For example, if you are starting work on version 3.2 of the Transaction Builder project, identify the baselines that represent the released, or production, versions of its version 3.1 components.
If you are converting a base ClearCase configuration to a project, you can make baselines from existing labeled versions. Check whether the latest stable versions are labeled. If they are not, you need to create a label type and apply it to the versions that you plan to include in your project.
After developers start working on the new project and making changes, create baselines on the integration stream and on any feature-specific development streams on a frequent (nightly or weekly) basis. This practice has several benefits:
Developers stay in sync with each other's work.
It is critical to good configuration management that developers have private work areas where they can work on a set of files in isolation. Yet extended periods of isolation cause problems. Developers are unaware of each other's work until you incorporate delivered changes into a new baseline, and they rebase their development streams.
The amount of time required to merge versions is minimized.
When developers rebase their development streams, they may need to resolve merge conflicts between files that the new baseline selects and the work in their private work areas. When you create baselines frequently, they contain fewer changes, and developers spend less time merging versions.
Integration problems are identified early.
When you create a baseline, you first build and test the project by incorporating the work delivered since the last baseline. By creating baselines frequently, you have more opportunities to discover any serious problems that a developer may introduce to the project inadvertently. By identifying a serious problem early, you can localize it and minimize the amount of work required to fix the problem.
Because baselines are an important tool for managing a project, define a meaningful convention for naming them. You may want to include some or all of the following information in a baseline name:
Project name
Milestone or phase of development schedule
Date created
For example: V4.0TRANS_BL2_June12
A promotion level is an attribute of a baseline that you can use to indicate the quality or stability of the baseline. ClearCase provides the following default promotion levels:
Rejected
Initial
Built
Tested
Released
You can use some or all of the default promotion levels, and you can define your own. The levels are ordered to reflect a progression from lowest to highest quality. You can use promotion levels to help you recommend baselines to developers. The Recommended Baselines dialog box displays baselines that have a promotion level equal to or higher than the one you specify. You can use this feature to filter the list of baselines displayed in the dialog box. Determine the set of promotion levels for your project and the criteria for setting each level.
Typically, software development teams perform several levels of testing. An initial test, known as a validation test, checks to see that the software builds without errors and appears to work as it should. A more comprehensive type of testing, such as regression testing, takes much longer and is usually performed by a team of software quality engineers.
When you make a new baseline, you need to lock the integration stream to prevent developers from delivering additional changes. This allows you to build and test a static set of files. Because validation tests are not exhaustive, you probably do not need to lock the integration stream for a long time. However, more extensive testing requires substantially more time.
Keeping the integration stream locked for a long time is not a good practice because it prevents developers from delivering completed work. One solution to this problem is to create a development stream to be used solely for extensive testing. After you create a new baseline that passes a validation test, your testing team can rebase the designated testing development stream to the new baseline. When the baseline passes the next level of testing, promote it. When you are confident that the baseline is stable, make it the recommended baseline so that developers can rebase their development streams to it.
For information on creating a testing development stream, see Creating a Development Stream for Testing Baselines. For information on testing baselines, see Testing the Baseline.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
