After a release is defined, you can run it multiple times on the journey to production. At the end of the software release life cycle, when the release process has been successfully completed and the software is ready for production, you can end the release. Once the release has ended, it cannot be run again.
Running the release
This example shows how to run a release called
Q1_TimeBaseRelease. You can start the release run when the release status is Release in planning and the Run button is enabled.
The release status changes to Release in progress and the Run button has been replaced by the button. Clicking on it shows a pop-up window with more actions. The Start and Target dates are in blue because the release is in progress.
When is displayed, human intervention is required for the pipeline to progress to the first stage. Clicking on it causes the Pipeline Run view for the
deployPipeline to be displayed.
The pipeline can progress after the user named john approves the entry to the QA stage of the pipeline. As the pipeline progresses, you can click in the QA stage to view the pipeline stage summary:
The pipeline continues to progress to the PROD stage after the required approvers respond at the exit gate. Progress continues until this release run is completed.
After the release is completed, you can start a new release run by clicking the button and selecting Re-run Pipeline. You can re-run the release as many as times as you want during the software release life cycle.
Viewing Jenkins build details in a CloudBees CD/RO release
Using the CloudBees CD/RO Jenkins plugin, continuous integration processes in Jenkins can be configured to trigger a CloudBees CD/RO release as a post-build action from either a Jenkins job or from a Jenkins pipeline task. In addition, the Jenkins job can be configured to:
Send Jenkins job information and pipeline run information to the CloudBees CD/RO release.
Attach a Jenkins pipeline run to a CloudBees CD/RO release.
Publish Jenkins build artifacts to the CloudBees CD/RO repository.
Releases triggered by Jenkins are denoted by pipelines on the Pipeline Runs list.
From the release dashboard, select a release. The Release Editor opens for that release.
Click Pipeline Runs. Pipelines triggered by Jenkins are denoted on the Pipeline Runs list with the Jenkins logo, as indicated in the image below.Figure 4. Pipelines triggered by Jenkins
To view the information sent by the post-build action from the Jenkins continuous integration process:
Select the Jenkins logo on the CloudBees CD/RO Pipeline Runs list entry or select View previous Pipeline Runs to choose a previous pipeline. The Jenkins build data screen appears.
Select the Details icon on the right of build entry. The console output summary, test results, and build artifacts for the Jenkins job appears in separate tabs as shown below.
The value in the Association column indicates how this pipeline run is associated with the CloudBees CD/RO release.
Triggered by CI: indicates the CloudBees CD/RO pipeline run is triggered by a Jenkins job or pipeline.
Attached: indicates a Jenkins post-build action attached the Jenkins pipeline run to the CloudBees CD/RO release.
Creating event triggers
Event-based triggers provide the ability to automatically run pipelines and releases based on external events, supporting continuous integration models. Trigger support in CloudBees CD/RO allows users to integrate with external tools such as source control management systems. For example, a Git repository can be configured to automatically trigger a release upon code check-in.
Webhook Triggers—An inbound, asynchronous event from a GitHub repository triggers an action such as run a pipeline or start a release.
Polling Triggers—An internal trigger is periodically sent to an external tool to determine if an event has happened such as a code check-in. And, if so, an action is initiated such as run a pipeline or start a release.
Configure event-based triggers as part of starting or rerunning a release: choose the Triggers action from the run button or the action button and configure them before you select Start Release. For further configuration information see Event-Based Triggers .
Aborting a release run
There are two ways to abort a release run.
During the first release run, you can abort it from the Release Dashboard. Clicking the button and selecting Abort Pipeline will abort the pipeline. The tasks that are currently running will finish, and no new tasks will be started. Release status appears as Aborted by admin.Figure 6. Release status Aborted by admin
During subsequent release runs, you can abort the current release run from the Pipeline Run view. Click the Abort button to abort the pipeline.Figure 7. Abort the pipeline
Click OK on the confirmation dialog. The tasks that are currently running finish, and no new tasks are started.
Completing the release
When you complete the release, no other actions can take place on it, and this action cannot be undone (reversed). The release cannot be run again.
You cannot end the pipeline that is currently running. If you want to end it, you must wait for this run to complete or abort it in the Pipeline Run view. For more information, see Aborting a release run.
If the release run is complete, you can complete the release from the release dashboard. Clicking the button and selecting End Release ends the release.
Click OK in the confirmation dialog; the Pipeline Run view now displays this status:
The release status is now:
The icon next to Release completed indicates that the release has been completed (ended).
The percentage complete icon on the right is split into two sections because the pipeline has two stages. It shows that the release run is 100% complete.
The target date has been replaced by the ended date.
The Started and Ended dates are in dark blue because the release is completed.
The Duration is the total time for the release.