Use Case one: Standard release delivery (SIT → UAT → STG → PROD)
This section provides an overview of the basic scenario for the Release Innovator pipeline usage to promote builds across environments in a controlled and repeatable way.
The pipeline enables consistent delivery by using build tags to identify and deploy the same release through different stages, from validation environments to production.
Define the Release Name
Define a unique release identifier used to track the deployment across all environments and distinguish it from other releases. Use any meaningful name (for example, a sprint identifier). This value is used as the “Release name” parameter in the Release Innovator pipeline.
Identify the initial CI pipeline Build Number
Determine the initial CI build to be used for SIT deployment and potential promotion to UAT environment.
This CI pipeline Build is the source of customizations for SIT deployment during release initiation. The same build can be used for UAT environment update, or it can be adjusted before approving the stage.
CI builds for STG and PROD are handled separately and require manual tagging.
Trigger the Pipeline
The following steps outline the process of running the Release Innovator pipeline:
- Navigate to the Release Innovator pipeline.
- Select Run Pipeline.
- Select the appropriate Branch/Tag.
- Set Release name defined previously.
- To skip deploying to SIT environment and start with UAT environment update, check Skip “Deploy SIT” stage option.
To tag identified initial CI pipeline for SIT and UAT check “Put tags on selected CI build for SIT and UAT environments” option, otherwise you will need to setup tags manually to promote the changes. It affects only “Tag CI build” stage.
Full concept of Release Innovator pipeline is based on environments and pipeline tags.
The appropriate pipeline stage automatically finds the CI build tagged with “SIT-ReleaseName”, “UAT-ReleaseName”, “STG-ReleaseName” or “PROD-ReleaseName” and uses its artifact to deploy or update the Aras Innovator.
- In Pipeline artifacts, select the CI pipeline build number you want to deploy to SIT or UAT. If “Put tags on selected CI build for SIT and UAT environments” option is not checked, the selected CI pipeline build should be tagged with “SIT-ReleaseName” manually in advance.
- Click the Run button.
As a result, Release Innovator Pipeline will start. The “Tag CI build” and “Deploy SIT” stages will pass automatically, if the appropriate options were selected.
Release Innovator pipeline will deploy new instance to SIT environment and deliver updates on top of existing instance in case of UAT, STG and PROD environments.
Environment Promotion Approval
When the pipeline reaches Update UAT stage, it will wait for approval.
- Before approving Update UAT stage please make sure that correct CI pipeline is tagged. If you want to deploy to UAT from specific UAT branch, make sure that CI pipeline from UAT branch has “UAT-ReleaseName” tag.
To review or update tags follow the steps:- Open the necessary CI Pipeline
- Review tags
- Click Add tags or Edit tags
- Add new tag
- Click Save button
- Review tags
- If you are running Release Innovator Pipeline for the first time, make sure that the innovator release name is specified in ReleasePipelineConfigValues group.
- If CI pipeline is tagged correctly, click on “1 check in progress”.
- Approve the stage.
“Update UAT” requires approval by “Business Owners” group.
Release Innovator pipeline will trigger the UAT update. You can find link to UAT pipeline inside Queue DeployInnovator on (UAT) and wait for completion step.
The process of updating STG environment is similar to UAT update. Before running Update STG, ensure the corresponding “STG-ReleaseName“ tag exists on the intended CI build (this is not applied automatically by the pipeline). “Update STG” requires approval by “Business Owners” group.
Obtain Production Approval
The process of updating PROD environment is similar to UAT and STG update. Before running “Update PROD”, ensure the corresponding “PROD-ReleaseName“ tag exists on the intended CI build (this is not applied automatically by the pipeline).
“Update PROD” stage requires approvals by “Business Owners” and “GCS Operators” groups.
After approval, the customization is promoted to production with full traceability through release naming, tags, and approval history.