4.3 Deliver Operations

This section describes the policies that affect deliver operations. You can set these policies to apply to all streams within the project or you can set the policies on a per-stream basis. When a developer starts a deliver operation, UCM checks the policy settings on the target stream and the project. If the target stream's policy setting is different than its project's policy setting, the project's setting takes precedence.

Allow Deliveries from Stream with Pending Checkouts

This policy allows developers to deliver work to the target stream even if some files remain checked out in the source stream. If you do not set this policy, developers must check in all files in their source streams before delivering work. You may want to require developers to check in files to avoid the following situation:

1. A developer completes work on an activity, but forgets to check in the files associated with that activity.

2. The developer works on other activities.

3. Having completed several activities, the developer delivers them to the target stream. Because the files associated with the first activity are still checked out, they are not included in the deliver operation. Even though the developer may build and test the changes successfully in the development work area, the changes delivered to the target may fail because they do not include the checked-out files.

Rebase Before Deliver

This policy requires developers to rebase their source streams to the target stream's current recommended baselines before they deliver work to the target stream. The goal of this policy is to have developers build and test their work in their development work areas against the work included in the most recent stable baselines before they deliver to the target stream. This practice minimizes the amount of merging that developers must do when they perform deliver operations.

Deliver Operations to Nondefault Targets

As shown in Figure 19, you can create a hierarchy of development streams. Such a hierarchy allows you to designate a development stream as a shared area for developers working on a particular feature. Developers who work on that feature deliver work to the feature-specific development stream.

Figure 19 Default and Nondefault Deliver Targets in a Stream Hierarchy

Within a stream hierarchy, streams have an ancestor-descendant relationship. In Figure 19, the integration stream and the Feature1 development stream are ancestors of the Developer1 and Developer2 development streams. Feature1, Developer1, and Developer2 are descendants of the integration stream. A stream's immediate ancestor is its parent stream. A stream's immediate descendant is its child stream.

Because a project can contain a set of complex development stream hierarchies, a development stream may deliver to numerous target streams within the project. In addition, streams may deliver to streams in other projects. The default target for a deliver operation from a development stream is that stream's parent stream. Developers may also deliver to nondefault target streams. The arrows in Figure 19 illustrate default and nondefault deliver targets. The following policies apply only to nondefault target streams.

Allow Deliveries from Streams in Other Projects

Set this policy to control whether streams accept deliveries from streams in other projects. See Chapter 9, Managing Parallel Releases of Multiple Projects, for examples of when you may want to deliver work from one project to another.

Allow Deliveries That Contain Changes in Foundation Baselines

UCM uses foundation baselines to configure a stream's view. A view attached to a stream selects the versions of elements identified by the stream's foundation baselines plus the versions of elements associated with any activities created in the stream. For example, in Figure 20, BL1 is the foundation baseline for the Feature1 development stream. The BLX baseline is the foundation baseline for the Developer1 development stream.

If the developer working in the Developer1 stream delivers work to the integration stream, the deliver operation includes the activities created in the Developer1 stream plus the files represented by the BLX foundation baseline. The integrator responsible for the integration stream may want to receive work that the developer working in the Developer1 stream has completed; however, the integrator may be unaware that the deliver operation also contains changes made in the BLX baseline. You may want to set this policy to Disabled so that target streams do not accept deliver operations that contain changes in the source stream's foundation baselines.

UCM contains two versions of this policy: one for interproject deliver operations, and one for intraproject deliver operations.

Figure 20 Delivering Changes Made to a Foundation Baseline

Allow Deliveries That Contain Changes Made to Components Not in Target Stream

Set this policy to control whether streams accept deliveries that contain changes to components that are not in the target streams' configurations. If you set this policy to Enabled, UCM allows the deliver operation, but the changes to any missing components are not included. UCM contains two versions of this policy: one for interproject deliver operations, and one for intraproject deliver operations.

Allow Deliveries That Contain Changes to Nonmodifiable Components

Set this policy to control whether streams accept interproject deliveries that contain changes to components that are not modifiable in the target stream's project. If you set this policy to Enabled, UCM allows the deliver operation, but the changes to any nonmodifiable components are not included.