Parallel stages in Azure DevOps release pipelines
Summarize
Summary of Parallel stages in Azure DevOps release pipelines
Parallel stages in Azure DevOps release pipelines allow tasks to be executed concurrently, enhancing automation and speeding up the release process. This feature is particularly beneficial for organizations that need to integrate multiple testing and quality assurance tools within their release pipeline.
Show less
Key Features
- Concurrent processing of parallel stages, displayed in real-time within the DevOps pipeline UI.
- Integration with ServiceNow to automatically create change requests that capture details from all upstream stages once processing is complete.
- Support for pre-deployment conditions and release gates that facilitate the creation of change requests linked to the production stage.
- Real-time visibility of the pipeline state and associated artifacts sourced from the build pipeline.
Key Outcomes
By leveraging parallel stages, ServiceNow customers can expect:
- Reduced execution time for release pipelines, as tasks are performed simultaneously rather than sequentially.
- Improved change management through automated change requests that summarize relevant information from upstream stages.
- Enhanced visibility into the pipeline's execution state, allowing for better tracking and management of deployments.
Note: Ensure that change requests do not exist in stages with parallel jobs to avoid potential deadlock scenarios during execution.
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.
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.