Create a release process

Release processes provide visibility into the activities that make up your release lifecycle, and help you identify issues and bottlenecks.

This topic describes how to design a release process.

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.

Release process items

The following table summarizes the items that can be included in a release 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.

There are two types of actions:

  • Manual action: An action that should be performed manually, such as deploying a Windows machine.

  • Auto action: An action to be executed automatically when the previous action is completed or when scheduled. For details, see Auto actions.

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 if environments are deployed correctly.


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

Auto actions

You can create auto actions of the following types: (Some of the auto actions are only Available in: ValueEdge and ALM Octane 16.0.400 and later.)

Type Input properties
ALM Octane action

The following are some of the ALM Octane common auto actions :

  • Generate document report. Generate a document report based on the selected document report template. The template drop down list only includes templates that are shared with all users. If the auto action is successful, the owner of the auto action is notified of the report generation in the My Work area. Note the following:

    • The report is generated on behalf of the API key for auto actions.
    • Document report templates that include widgets are not supported.
    • The report is not available for users with data access control enabled. For details, see Data access control (Enterprise Edition).
    • If the auto action is deleted, the generated report will no longer be available.
    • Admins can configure email templates to include a link to the auto action generated document report.
  • Send email. Sends an email with a specific message. You specify the To, CC, and BCC fields, the subject, content, and importance level.

  • Update entities. Performs an update to the specified entity. If the auto action is successful, new values will replace the original values, for all the selected item types that comply with the filter definition. You specify the following values:

    • Entity type: The type of items that the auto action should update.
    • Fields to update: The item fields that the auto action should update. You can also add tags. Define values for the specified fields.
    • Add Filter. Narrow down the list of items using a filter. For example, you can add a filter to update only those features linked to the current release process.
Run job

For a CI action, you specify the following:

  • CI server: The CI server whose job the auto action should trigger, such as Jenkins, Bamboo, Azure DevOps, PulseUno, GitLab, or TeamCity.
  • CI job: A job that the auto action should execute, depending on the selected CI server.
  • Execution parameters: Job execution parameters that ALM Octane should pass to the CI server.


    • The parameters are defined with the default values, or the latest values set on the CI server. To change a value, clear the default value and enter a new one.
    • The newly defined values are fixed for a job that the given auto action should run. They are not affected when values on the respective CI server change.
    • If the execution parameters are not defined in the auto action details, the CI job runs with the parameters set on the CI server. You can check the parameter details in the execution message.
  • Branch name: The branch on which the job should run.

    • Note:

      • PulseUno jobs: If the PulseUno parameters, such as a branch name and a changeset ID, are not defined, the auto action triggers a job on the latest changeset ID and the default branch.
      • GitLab jobs: If the branch name is not defined, the auto action triggers a job on the default branch. The same applies to multi-branch GitLab jobs.
      • Jenkins jobs: You must define a branch name for a Jenkins job. If the branch name is not selected, the auto action will fail.
Run application process

For deployment automaton, you specify a CD server, the application, its environment, a process, and a snapshot.


  • The API key for auto actions is a user account with the Release Manager role. It is used to perform system actions that are logged and require authentication. For example, when ALM Octane items are updated by an auto action, the updates are recorded in the item's history as the action performed by the API key for auto actions.
  • The API key for auto actions is defined for a release process. Only users with the Workspace Admin or Release Manager roles can define the API key.

Back to top

Create a process

The following sections describe how to define the elements of a release 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.

    Click Add Shared Release Process to create a release process in all the shared space's workspaces.

  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 it and edit the copy.. The structure of the existing process will be copied to the new process. The phase of the new process will be set to Planned. You can then modify its details and elements.

To duplicate an existing process:

  • In the processes list, select the checkbox adjacent to a process. Expand the More dropdown and select Duplicate.
  • Alternatively, right-click a release process and click the Duplicate button .

Back to top

Define stages

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

For example:

Stage Details

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 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 part of a stage.


Ensure that the following prerequisites are met for the following auto actions:

  • Run job: Ensure that the necessary ALM Octane integrations are configured for your workspace. For details, see ALM Octane integrations overview.
  • Update entities: Ensure that the API key for auto actions is defined for a release process.
  • Generate document report: Ensure that API key for auto actions is defined, and that the API key has the Generate Document Report permission from the General System Actions category. If necessary, contact your admin to grant this permission to the API key user. Also make sure that you have defined at least one document report template. For details, see Create a report template.

To define an action:

  1. Click + Manual Action or + Auto Action. If one option is not visible, expand the dropdown.
  2. Associate each action with the appropriate parent stage or group.

  3. Assign the action to an owner.
  4. For Auto actions: Select the action type and provide the field values. For details, see Auto actions.

  5. Click Add.

Tip: You can organize multiple actions into groups. You can reorder items in the process tree, but you cannot drag an item above an item that has already started. 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.

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 be 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: Does the feature have the owner and QA owner? Is the API impact verified?

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. Open a release process and click the Process Flow tab.
  2. Click + Quality Gate . If this option is not visible, expand the item dropdown and select + Quality Gate. For details, see Release process items.
  3. In the Add Quality Gate window, enter your information. Click Add & Edit.
  4. Click the Criteria tab. Choose a criterion type: + User Input Criterion or + Query Criterion.

  5. In the Add Criterion window, 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 for a quality gate.

Click + Query Criterion, and in the Add Query Criterion 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 items by defining a filter.

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 Linked Processes > Releases. Select Release Process.Releases in the popup, and click OK.
  • If you want the query to match the milestone defined for the release process, select Linked Processes > Milestones. Select Release Process.Milestones in the popup, and click OK.

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 versus 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: