Share this page

# 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.

In this topic:

## 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
--- | ---
Stage | The main component of a release process. Example: Prepare test environments
Action | 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.
Group | 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:

Type | Details
--- | ---
Run job | Triggers jobs on the CI server, such as Jenkins and PulseUno server. Available in: ValueEdge and ALM Octane 16.0.400 and later. You can also create auto actions to run jobs on the GitLab server.
Update entities | Available in versions: 16.0.300 and later Bulk-updates fields for ALM Octane items, such as features and backlog items. Note: ALM Octane items are updated on behalf of the API key for auto actions.
Generate document report | Available in: ValueEdge and ALM Octane 16.0.400 and later Generates a document report from ALM Octane based on the selected template. You can select only from those templates that are shared with all users. For document reports generated with auto actions, consider the following notes: The report is generated on behalf of the API key for auto actions. The report is not available for users with data access control enabled. For details, see Data access control (Enterprise Edition). Templates that include widgets are not supported. If the corresponding auto action is deleted, the report will no longer be available.

Note:

- 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.

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

Back to top

## 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

## Define stages

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

For example:

Stage | Details
--- | ---
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 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.

Prerequisites

Auto actions: Ensure that the following prerequisites are met:

- 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.

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. Auto actions: Select the action type, and define the following fields:

   Type | Details
   --- | ---
   Run job | CI server: The CI server whose job the auto action should trigger, such as Jenkins, PulseUno, or GitLab server. 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. Note: 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.
   Update entities | Entity type: The type of items that the auto action should update. Narrow down the list of items using the filter. Fields to update: The item fields that the auto action should update. You can also add tags. Define values for the specified fields. 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.
   Generate document report | Select a template from the Report template drop down. Note: The drop down includes only those templates that are shared with all users. The templates that include widgets are not supported. If the auto action is successful: The owner of the auto action is notified of the report generation in the My Work area. Users with the data access control disabled can download the report or copy the report link.

5. Click Add.

You can organize several actions into groups.

Note:
- 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 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: 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.
Filter | 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.

Note:

- 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: In the Process Flow grid, click the time field to enter edit mode. Adjust the time or duration manually, or click the pin icon. To unpin a time field: In the Process Flow grid, click the time field to enter edit mode. 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

## Permissions

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:

- Run a release process

https://admhelp.microfocus.com ALM Octane 8942
Tips to improve your search results... ValueEdge & ALM Octane Help Center ValueEdge ALM Octane Help 16.0.100-16.0.400 All View Local Help Center View Online Help Center back Go back in browser history forward Go forward in browser history Remove search highlights next topic Go to next topic previous topic Go to previous topic Print the current topic Version: