Change Package Overview

A change package is a group of changes made by a single user that can be considered a logical unit of work. Only the creator of a change package can add entries to that change package. Change package entries are added when you specify a change package while performing member operations.

A change package acts as a log of both the changes to members and subprojects that have already been committed to the repository (server), and the changes that are only visible to the user on the desktop and not committed to the repository (deferred). When change package reviews are mandatory, a change package acts as a control placed on changes to the repository by making them pending before they are committed.

A change package is open until you close it, which signifies that work on the change is completed. When reviews are mandatory, a change package has additional states before it is closed.

The following rules apply when using change packages:

• Each change package has a unique change package ID (CP ID). The CP ID is a colon separated identifier of the form:

If the Integrity Lifecycle Manager integration is enabled, the item ID is used as the container ID.

• Only the creator of a change package or a change package administrator can close a change package. However, if a change package is empty, other users can also close or discard the empty change package if they have the ManageEmptyChangePackage permission at the global level.

• Once a change package is closed, it can only be re-opened by a change package administrator. If a change package has been propagated through Apply CP or Resync CP, it cannot be reopened, even by a change package administrator.

You can expand the capabilities of change packages by associating them with items to take advantage of Integrity Lifecycle Manager’s workflow and document management.

As part of integrating with workflows and documents, you can associate change packages with Integrity Lifecycle Manager items. Items provide more detailed information on the action that is required and control the workflow of development and testing, known as the software development cycle.

Integrity Lifecycle Manager items track changes in the software development cycle. For example, your administrator can configure Integrity Lifecycle Manager in a way that a problem item may be associated with a solution item for easy tracking and monitoring of both items. Each item has an audit trail, which may be used to evaluate internal processes for the effectiveness of the problem resolution process. In effect, items track all aspects of any engineering project.

Integrating with workflows and documents allows you to specify groups of developers who are affected by an item, who can then be notified using e-mail notification rules.

Administrators define what item types can use change packages and configure software configuration management to integrate with process and workflow management.

Change packages can be grouped together using an item to create a larger logical grouping of changes. Each change package in an item can be created by a different user for team development of an item.

Note the following rules that apply when using items and change packages:

• Multiple change packages can be created for a single item. If the resolution of an item requires more than one set of changes, a new change package can be created for each new set of changes. This also allows multiple users to work on the same item.

• If an item type does not allow open change packages, you cannot create and associate new change packages with that item. Check with your administrator to find out which item types allow open change packages.

• Only item states specified by your administrator allow open change packages. When attempting to advance to a state that does not allow open change packages, Integrity Lifecycle Manager instructs you to first close the item’s change package.

• Typically, an item cannot advance to the final state in an Integrity Lifecycle Manager workflow until all change packages are closed. See your administrator for more information.

• When workflows are enabled, the change package ID is a colon-separated identifier of the form:

Change packages provide the following advantages:

• Change packages allow work in progress to be submitted to the repository (server) all at once (using submit change package), which prevents users from partially submitting related work in progress.

• Change packages provide a way to apply related changes to a project or Sandbox in one operation.

• Using change packages, users are able to resync the changes required to address a specific item without resyncing the entire project.

• Groups of changes can be reviewed as a unit. If reviews are mandatory, changes are reviewed before they are committed to the server repository.

The following is an example of a way to use change packages to control development. You can combine this example with the review process to control what changes become a permanent part of the repository.

2. Create a change package for the group of tasks you need to perform to address an item. When creating the change package associate it with the item you created.

3. Integrity Lifecycle Manager assigns the change package an ID and leaves the change package in an open state. You can see the change package listed in the Change Packages view.

4. As part of your development process, identify the members that are affected by the item. Specify the change package when performing operations on the affected members. The operations are listed in the Change Package view.

5. When all of the development to address the item is completed, submit the change package. Any locked members are converted to deferred checkin operations, then checked in. All of the deferred operations are submitted.

6. Close the change package when the work to address the item is completed. The change package is moved to the Closed state, and the change package disappears from the Change Packages view.

7. Advance the item through the workflow. At this point, the verification phase begins. If it is determined that more work needs to be performed to address the item, the user moves the item to an earlier state in the workflow, then you (or another developer) create an additional change package. The process is repeated until the item is sufficiently addressed.