Control changes

This chapter explains the options for tracking changes in Dimensions CM.

Track issues and enhancements

In Dimensions CM, you can use the following change-tracking systems:

  • Native Dimensions CM requests.

  • External requests from one of the supported request providers, such as Micro Focus ALM Octane or Atlassian Jira.

You track issues, bug reports, or enhancement requirements in Dimensions CM using these requests. You manage changes to items by relating groups of items and requests together. For details about these relationships, see Link version management and change management.

You can relate groups of Dimensions CM requests to a parent request, which enables you to track all the involved items as a set of related changes.

With Dimensions CM requests (but not with external requests) you can create a frozen configuration of items as a baseline by including or excluding the items related to a set of requests together with other selection criteria, such as the request’s status. This enables you to record and recreate the configuration for a particular strand of development.

For an overview of the change management tasks, see Change management.

Back to top

Package requests

For native Dimensions CM requests, a useful way of including the correct items in a build is by packaging them together under a single parent request or requirement.

You can also use requests to merge a set of changes from one project or stream to another. You can relate these changes to a request in the following ways:

  • Files to be updated can be directly related to the request.

  • The request can consist of other related child requests to form a hierarchy.

  • The request can have various types of other requests (defects, enhancements, or issues) related to it with their associated related items.

The package request also has a lifecycle to reflect the approval process for the set of changes.

For example, the package request might move from the Planning state to Under Work. Developers fix issues, relating the changed files to the requests. The items to which the requests are related are included in the package request. If during development it becomes clear that a particular enhancement will not make the build date, the enhancement can be unrelated from the request.

The changes can then be built. When all work is complete, the package request can move to state QA.

Back to top


In Dimensions CM you can create a baseline. A baseline is a frozen configuration of the items versions that went into a particular deployment of a project/stream or strand of development.

You can use baselines to create projects or streams from which another development can begin, for example:

For an overview of baselines and baseline types, see Baseline management.

Back to top

Work areas

You can associate a project or stream with an area on your machine, or an area located on another part of the network. When you check out the items under development, they are copied to that area and are under the required folder/directory structure. This area is called a work area.

You can associate your own separate area with a project/stream or associate an area which is shared by a team.

Such areas can also be defined under Dimensions CM control in the Administration Console by associating them with a Dimensions CM-defined network node and folder location.

For details on how to create work areas in the Dimensions CM clients, see the following topics:

Web client Create a work area
Desktop client Create a work area

Deployment areas

In Dimensions CM, you can define deployment areas for projects/streams whose items have reached a particular stage of development.

The term deployment in Dimensions CM refers to the process of copying item files to a controlled location when they have reached a particular stage of development.

You can define stages in your software development lifecycle, such as Development, QA, LIVE, and you can have item files automatically copied to the associated areas when the files have reached the corresponding state of approval for that particular stage.

This process of approval is called promotion and is linked to the Global Stage Lifecycle (GSL) that items follow through the deployment process. Deployment areas are associated with the GSL stages.

There is a single GSL defined for the base database, but you can change this or configure your own GSL. Stages in this lifecycle can also be associated with the lifecycle states defined for different types of objects, so that the two processes can be linked.

You can apply filters to deployment areas to determine the types of files the area can contain. For example, you may have different areas for software versions for different operating systems.

When items are promoted to a stage, they can be automatically deployed to one or more areas associated with that stage, or your can deploy them manually later. You can schedule deployments for a specific date and time.

Dimensions CM enables you to promote files, Dimensions CM requests, and baselines. See Promote objects.

For details about Dimensions CM deployment, see Use Dimensions deployment.

Back to top

See also: