The release 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 sections provide details about the release process items and their time frames.

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.

    Tip: To further automate your auto actions, use variables to parameterize the values of your action's fields. For details, see Run a process with variables.

Quality Gate

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

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, the action's start time is 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 is 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 stays 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 is automatically 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.

Back to top

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.

Tip: Hover over the Start time and End time fields to open a popup showing the actual vs. planned times.

Back to top

Execution flow with variables

This section describes a typical flow, using auto actions, quality gates, and variables in the release process flow.

The use of variables allows you to automatically connect the stages of your testing process with up-to-date and relevant data.

Note: Variables are available from ALM Octane 16.2.100.

Stage Action Input variables Output variables

Run a nightly build

 Auto action: Nightly build  

  • version number

  • nightly build number
Deploy the environment

Auto action: Deploy QA env

  • version number

  • environment URL
Run sanity tests

Auto action: Sanity tests

Quality gate: No failed runs for critical tests in latest nightly build. Criterion filters test runs by job name and build number.

  • environment URL

  
Run additional tests - Stage 1

Auto action: Run UFT One tests

Quality gate: check that all tests were executed.

  • version number

  • list of suites

  • environment URL

  • results (num passed, num failed, num skipped),

  • link to UFT One report

  • UFT One build number
Run additional tests - Stage 2

Auto action: Generate doc report with results of run, suing a template that shows last runs from last day, per job name.

 

  • link to doc report
Send notifications

Auto actions:

  • Send email to QA manager including the results, link to doc report, link to UFT One report.

  • Send email to users indicating that the nightly build passed, version number xxx, and it was deployed on <env> URL.

  • link to doc report

  • version number

  • environment URL

  
Run updates

Manual actions:

  • Filter for defects fixed in current version.

  • Update entities by marking defects as ready for verification.

    

Back to top

Next steps: