Motadata Docs

Release Workflow

Workflow Introduction

Every release is processed through a series of steps that requires some activity and decisions. The whole life cycle is called the release workflow. In an organization, the release management is applicable on activities, infrastructure, processes, environments, etc. In the release management system, there is a workflow to track the activities, and decisions at various stages of the release. Based on the requirements, the workflow can be default for instant use or customizable to meet the business needs.

A simple release workflow has the following states:

Release Workflow States
Release Workflow States

Workflow in the system has a pre-defined structure. All the releases are directed through the workflow only. The high level characteristics of the workflow are:

  • The workflow has 8 stages.
  • The stages in the workflow are fixed.
  • You cannot move back to the previous stage from the current stage.
  • System locks certain functions once a stage is complete. For example: In the approval stage, you cannot make changes in the planning schedule or add notes.
  • Once a release is rejected at any stage, the workflow can be initiated again from the planning stage.

The Workflow States

Submitted: This is the first stage of the workflow. The state is assigned automatically to every new release request. At this stage, a concerned person will review the release ticket and may add more details to the ticket. Also, someone will take a decision. The decisions can be: Requested, Accepted, and Rejected.

Submitted Requested
  • First and default stage.
  • Concerned person will accept or reject the release.
Accepted
  • A technician should be assigned before accepting the release.
  • The release is accepted and someone will work on it.
  • The release request moves to planning stage.
Rejected
  • The release is rejected and no action will be taken on it.
  • The release workflow is terminated.

Planning: In the planning stage, a concerned person decides how to implement the release. You can manage the activities related to the planning in the tabs at the bottom.

Planning In Progress
  • Default status of the stage.
  • Concerned person will complete or cancel the planning.
Cancelled
  • The release is rejected and no action will be taken on it.
  • The release workflow is terminated.
Completed
  • The planning is completed with all necessary details.
  • The release request moves to the approval stage.
  • Planning, Tasks, and Relation tasks are locked to prevent editing.

Approval: In the approval stage, concerned persons have to give the approval. In this stage only the following releases are allowed: Technician, Assignee, and collaboration items. If you do not see the Approval tab at the bottom of the page, you will need to ask for approval. See more details on Release Approval.

Approval In Progress
  • Default status of the stage.
  • Concerned person will approve or reject the release.
Approved
  • The release is approved.
  • The release request moves to the Build stage.
  • Tasks, Work log, and Relation tasks are opened again for editing.
Rejected
  • The release is rejected and no action will be taken on it.
  • The release workflow is terminated.

Build: In the build stage, concerned people provide the planning of the build. In this stage the only changes allowed are: Custom Fields and other details.

Build In Progress
  • Default status of the stage.
  • Concerned person will approve or reject the build.
Cancelled
  • The build is cancelled and no action will be taken on it.
  • The release workflow is terminated.
Completed
  • The build release is completed with all necessary details.
  • The release request moves to the Testing stage.

Testing: In the testing stage, the QA people are allotted to perform and apply changes while deploying the release. In this stage the only changes allowed are: Custom Fields and all other details. And the changes not allowed are: Release Manager and Release Engineer.

Testing In Progress
  • Default status of the stage.
  • Concerned person will test the release.
Failed
  • The release testing is failed.
  • The release workflow can be initiated again from the planning stage.
  • The release workflow is terminated.
Completed
  • The testing of release is completed and move to the Deployment stage.

Deployment: In this stage, the release actually takes place. You can manage the activities related to the deployment in the tabs at the bottom of the page.

Deployment In Progress
  • Default status of the stage.
  • Concerned person will perform or reject the deployment.
Failed
  • The release deployment is failed.
  • The release workflow can be initiated again from the planning stage.
  • The release workflow is terminated.
Completed
  • The deployment of release is completed and move to the In Review stage.

In Review: In this stage, the release review takes place. You can manage the collaboration and work log in the tabs at the bottom of the page.

In Review In Progress
  • Default status of the stage.
  • Concerned person will review the release.
Failed
  • The release review is failed.
  • The release workflow can be initiated again from the planning stage.
  • The release workflow is terminated.
Completed
  • The release review is completed and move to the Close stage.

Close: In this stage, the release process is closed. This stage is automatically assigned when the review is completed. After close, you can reopen the release request.