Control changes

This chapter explains the options for tracking and deploying 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 supported request providers, such as OpenText 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 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.

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. Such a work package can be closed only when all its requests are closed.

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 doesn't 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 the QA state.

Use baselines

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.

Define work areas

A work area is the location you use for working with files:

A folder on your local machine, for example, C:\myworkarea.
A folder on a remote node, specified by the syntax <nodename>::/<folder>, for example, UNIX::/myworkarea.
A managed work area that you can create in the desktop client, web client, or Administration Console. This area can be used by other users as their project work area. For details about area definitions, see Set up the process model.

The work area's folder structure is identical to that of the project/stream. For an overview of projects and streams, see Control assets.

When you check out items under development, they are copied to your work area and are under the required folder structure. Changing your work area doesn't change the default for other users of the same project.

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, see the following topics:

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

Define deployment areas

You can define deployment areas for projects/streams whose items have reached a particular stage of development.

In the Dimensions CM deployment model, deployment is 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.

You can promote files, Dimensions CM requests, and baselines. 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.

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

Deploy your changes

Dimensions CM supports the following deployment models:

Dimensions CM deployment (default)
Deployment Automation

For details about using each model, see Continuous deployment.