Parallel stages in Azure DevOps release pipelines
Summarize
Summary of Parallel stages in Azure DevOps release pipelines
ServiceNow DevOps now supports the concurrent processing and real-time display of parallel stages in Azure DevOps release pipelines. This enhancement enables organizations to accelerate release processes by running multiple jobs or tests simultaneously rather than sequentially. The DevOps pipeline UI mirrors the Azure DevOps GUI, showing detailed progress and results of each parallel stage.
Show less
Important to note, this parallel stage support applies only to release pipelines; build pipelines continue to display stages sequentially in the DevOps UI.
Key Features
- Parallel Stage Execution: Allows multiple stages, such as unit tests, integration tests, and nested parallel tests, to run simultaneously, reducing overall pipeline duration.
- Real-Time Pipeline UI: The DevOps pipeline UI presents parallel stages visually and updates in real time, providing transparency into each stage’s status and results.
- ServiceNow DevOps Release Gate Integration: Pre-deployment conditions now include a release gate that triggers creation of change requests before deployment to production. These change requests aggregate details from all upstream parallel stages, including commits, work items, test summaries, software quality reports, and artifact versions.
- Change Request Automation: Once all upstream parallel stages complete, a change request is automatically created and linked to the production deployment stage. The production stage proceeds only after change request approval.
- Pipeline Execution Details: Users can access detailed pipeline execution views, including artifacts and test quality results, directly from the DevOps UI.
Job and Change Request Processing Considerations
Azure DevOps provides job completion notifications sequentially even if jobs run in parallel, which can cause a deadlock during change request creation if parallel jobs are still queued. This may result in a 500 error in the event API due to timing conflicts. Rerunning the job typically resolves this issue by marking previously queued parallel jobs as completed.
Upgrade Considerations
- Change requests should not be the first job in a stage that contains parallel jobs to avoid processing conflicts.
- Fresh installations will not display the Upstream execution column in the Task Executions table; existing customizations remain unaffected.
- After upgrading, new release pipeline executions will display and process parallel stages concurrently, while previously executed pipelines remain displayed serially.
- If the pre-deployment ServiceNow DevOps release gate is enabled on multiple start stages within a pipeline, multiple pipeline executions may occur. Each start stage creates a separate package, but only one package is associated per pipeline execution.
Practical Impact for ServiceNow Customers
By leveraging parallel stages in release pipelines, customers can significantly reduce release cycle times and improve pipeline efficiency. The integration with ServiceNow DevOps release gates ensures governance through automated change requests that capture comprehensive upstream stage details. Understanding the potential deadlock scenarios and upgrade prerequisites helps maintain smooth pipeline execution and change management compliance.
Parallel stages in a release pipeline are now processed concurrently and displayed in the DevOps pipeline UI in real time. Base system pre-deployment conditions and release gates enable you to create change requests that include details from parallel stages.
Base system parallel stage support for Azure DevOps
Organizations use parallel stages to automate and speed up release processes for tasks that can be performed in parallel. For example, a release pipeline has integrated multiple test and software quality tools and has jobs configured to run in parallel. Not running each job sequentially significantly speeds up the release pipeline execution.
ServiceNow DevOps supports processing parallel stages in release pipelines and displays the stages in a parallel view in the DevOps pipeline UI. Effectively, the DevOps pipeline UI replicates the Azure DevOps GUI in real time.
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building...'
// Your build steps here
}
}
stage('Test') {
parallel {
stage('Unit Tests') {
steps {
echo 'Running unit tests...'
// Your unit test steps here
}
}
stage('Integration Tests') {
steps {
echo 'Running integration tests...'
// Your integration test steps here
}
}
stage('Additional Tests') {
steps {
script {
parallel(
'Nested Stage 1': {
echo 'Running nested parallel stage 1...'
// Your nested parallel stage 1 steps here
},
'Nested Stage 2': {
echo 'Running nested parallel stage 2...'
// Your nested parallel stage 2 steps here
}
)
}
}
}
}
}
stage('Deploy') {
steps {
echo 'Deploying...'
snDevOpsChange changeRequestDetails: '{ "attributes": {"chg_model": "e55d0bfec343101035ae3f52c1d3ae49","standard_change_template"="563504cc47410200e90d87e8dee490e2"},"autoCloseChange": false}',changeStepTimeOut: 18000, pollingInterval: 60
// Your deploy steps here
}
}
}
}
ServiceNow® DevOps release gate in pre-deployment conditions to create Change requests
- Commits
- Work Items
- Test Summaries
- Software Quality Summary
- Artifact Versions
After the pipeline execution completes processing the parallel stages preceding the production deployment stage, a change request is automatically created and mapped to the deploy to production stage in the Pipeline Executions view. The production stage completes processing once the change request is approved.
From the Pipeline Execution view of the relevant pipeline, click the Pipeline UI related link to view the real-time state of the pipeline as it appears in Azure DevOps. The associated artifact details which are sourced from the build pipeline, Test Results, Software Quality Summary Results display on the pipeline UI.
Change creation sequence for parallel jobs
Job information from Azure is received in ServiceNow during the following times:
- Upon the completion of a stage.
- When the register-change step executes.
Azure provides job information sequentially based on job queue time, despite jobs potentially running in parallel. Consequently, if the register-change step executes while a parallel job queued earlier remains unfinished, the system assumes the parallel job is an upstream task, causing the change creation process to wait for its completion. However, stage completion notifications are not received until all jobs, including the register-change job, have finished.
This creates a deadlock scenario where the change process in ServiceNow waits for the parallel job to complete, while the parallel job waits for the stage completion notification, which in turn waits for the register-change job to finish.
Due to this deadlock, by the time the change is created, the Azure pipeline job has already failed, leading to the 500 error in the event API. Rerunning the job resolves the issue as the previously queued parallel jobs are marked as completed.
Upgrade Considerations
- The Upstream execution column in the Task Executions table is not displayed for fresh installations. Any customizations that you have made using the Upstream execution column prior to the upgrade are unaffected.
- If stages are running in parallel, a change request should not be the first job in any stage.
- After upgrading, new release pipeline executions process parallel stages concurrently and display parallel stages and associated details in the pipeline UI. Azure DevOps release pipelines that are already executed and stored in ServiceNow DevOps prior to the upgrade remain unaffected and continue to display parallel stages (that are already executed and persisted) in ServiceNow DevOps serially.
- If the pre-deployment ServiceNow DevOps release gate is enabled in more than one start stage in a release pipeline with multiple start stages, it might result in multiple pipeline executions.