Create a release process

This topic describes how to design a release process. Release processes include stages. Each stage consists of actions and quality gates.

Create a process

First, you need to create a release process, and then define its stages and actions.

You can either create a new process from scratch, or duplicate an existing process.

To create a new release process:

  1. Select Release Management > Processes.
  2. Click Add Release Process to create a release process in the current workspace.

  3. Assign the process to a release or milestone. Fill in other process fields.

If you have an existing process from a previous release, you can duplicate the process. The structure of the existing process will be copied to the new process. The phases of the new process will be set to "Planned". You can modify the new process' details and elements.

To duplicate an existing process:

  • In the processes list, select a process and click Duplicate.

Back to top

About the process flow

A release process is made up of a number of stages. Each stage contains actions, manual and automated, and quality gates.

Optionally, you can organize actions and quality gates into groups.

The following table summarizes the items that can be included in a process:

Item type Details

The main component of a release process.

Example: Prepare test environments


A task that should be performed as part of a stage:

Manual action

Should be performed manually. For example, deploying Windows machine.

Auto action

Available in versions: 16.0.200 and later

You can create auto actions to run jobs on your Jenkins server. An auto action is executed automatically when the previous action is completed or when scheduled.

Note: To trigger Jenkins jobs, ensure that CI server integration is configured for your workspace. For details, see ALM Octane integrations overview.

Quality Gate

A step that ensures that a set of criteria is met before moving on to the next stage or action. For details, see Define quality gates.

Example: Check that environments are deployed correctly.


An optional container for actions and quality gates. A group can contain lower level groups.

The following sections describe how to define different elements of a release process.

Back to top

Define stages

Stages, as well as groups, can be defined as parallel or sequential:

Parallel All child actions are run at the same time.
Sequential An action starts after the preceding action has completed.

To define a stage:

  1. Open a release process and select the Process Flow tab.
  2. Click Stage to create the first stage in the process.

    Use the Run children in parallel field to determine whether the stage's or group's child items can be executed at the same time.

After creating a stage, define actions and quality gates that make up the stage.

Back to top

Define actions

Actions represent tasks that should be performed as a part of a stage.

To define an action:

  1. Click Add and select Manual Action or Auto Action.
  2. Associate each action with the appropriate parent stage or group.

  3. Assign the action to owner.
  4. For an auto action to run a Jenkins job, define the following:

    Action type Select Jenkins - Run job.
    CI server Select the integrated server.
    CI job Select the Jenkins job that an auto action should run.

You can organize several actions into groups.

  • You can reorder items in the process tree. To reorder an item, drag the item up or down the tree. After you move the item, the timings of the surrounding items are adjusted automatically.
  • You cannot drag an item above an item that has already started.

Back to top

Define quality gates

Use quality gates to verify that certain criteria are met before moving to the next stage.

For a quality gate to pass, all its criteria need to marked as passed.

Quality gate criteria can be a combination of user input and query criteria:

Criterion type Description
User input criterion

You enter a textual description of a condition for passing the quality gate.

The owner manually marks the criterion as passed or failed.

Examples: "Feature has owner and QA owner?", "Checked API impact?"

Query criterion

You define a rule that checks whether the number of items of a selected type within a given filter meets a specified condition.

When the quality gate is processed, the system automatically runs the query. If the condition is met, the criterion is passed. If the condition is missed, the criterion is failed.

Example: Defects = 0; Filter: Severity = {Very High, Critical}, Feature = {my feature}

To define a quality gate:

  1. Click Quality Gate and define the quality gate's basic properties.
  2. Open the quality gate's details.
  3. On the Criteria tab, click either User Input Criterion or Query Criterion . Define a condition for passing the quality gate.

For details on defining query criteria, see Define query criteria for quality gates.

Note: The number of criteria that you can define in a quality gate is controlled by the RC_CRITERIA_PER_GATE parameter. For details, see Configuration parameters.

Back to top

Define query criteria for quality gates

This section describes how to define query criteria in a quality gate.

Click Query Criterion , and in the new dialog box, provide the following details:

Field Description
Item type

Select the item type that the query will run on. You can reduce the scope of the items by defining a filter. See below.

Possible values: Backlog Items, Defects, Last Test Runs.

Threshold operator/ Threshold value

Use these fields to define a numerical condition. If the condition is met, the criterion passes.


Set a filter to define the subset of items that the system compares with the threshold condition.

  • If you want the query to match the release defined for the release process, select the Release Process.Releases value.
  • If you want the query to match the milestone defined for the release process, select the Release Process.Milestones value.

Setting these values lets you define the release and milestone for all the query criteria in one place, on the Details tab of a release process. Also, if you reuse the release process as a template, you will not have to modify the release and milestone values for every query criterion individually.

For details on setting filters, see Define filters.

Simulate query criteria results

You can run a simulation of a query to see how many items the query returns, and see whether the query would pass or fail the criterion.

To simulate the results:

  1. In the Criteria grid of the quality gate, select the criterion that you want to simulate.
  2. In the Preview pane of the query criterion, click Simulate Results.

    After the simulation completes, a flag displays in the Preview pane indicating whether the criterion would pass or fail given the current situation.

  3. Click the results link to list the items that the query returned.


  • You can simulate query criteria of quality gates that are in the "Planned" phase only.
  • The simulation reflects the current situation. The results of the actual quality gate evaluation may be different.

Back to top

Date and time fields

Each item in a release process, including the release process itself, includes three time-related fields: Start time, End time, Duration.

The following table describes actions you can perform on date and time fields:

Action Details
Auto-adjust times

After you set two of the fields, ALM Octane automatically sets the third field. For example, if you set an action's end time and duration, its start time will be calculated automatically based on the two other values.

In addition, ALM Octane automatically sets the start time of an item to coincide with end time of the preceding item. For example, if the last action of a stage is set to end at 3/4/2021 10:00, the next stage will be scheduled to start at that time.

After modifying any of the time values, ALM Octane automatically adjusts all the time fields that are impacted by the change.

Pin time fields

You can pin any of the time fields in a release process item. Pinning the field instructs ALM Octane to keep the value fixed, and not adjust the value automatically when other time fields are changed. For example, if you have a firm date on which a testing action must begin, you can pin the Start time field. Now, even if you edit the end time of the preceding item, or the testing action's end time and duration, the start time will stay fixed.

To pin a time field:

  1. In the Process Flow grid, click the time field to enter edit mode.
  2. Adjust the time or duration manually, or click the pin icon.

To unpin a time field:

  1. In the Process Flow grid, click the time field to enter edit mode.
  2. Click the pin icon.

    The unpinned time or duration will automatically be calculated according to the surrounding time values.

Set the format of time fields

By default, the Start time and End time fields display the date and time, and the Duration field displays the duration in days, hours and minutes.

Use the HIDE_HOURS_AND_MINUTES_IN_RELEASE_CONTROL parameter to display the date only.

For details, see Configuration parameters.

Actual vs. planned times

After an item is started or ended, the actual start time, end time, and duration are stored in the Actual start time, Actual end time, and Actual duration fields.

You can also hover over the Start time and End time fields to view in a popup the actual vs. planned times.

Back to top


Access to the release process settings depends on permissions granted to your user role.

For details, see Assign roles and permissions.

Back to top

See also: