Release gates and approvals overview
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.
Release pipelines enable teams to continuously deploy their application across different stages with lower risk and with faster pace. Deployments to each stage can be fully automated by using jobs and tasks.
Teams can also take advantage of the Approvals and Gates feature to control the workflow of the deployment pipeline. Each stage in a release pipeline can be configured with pre-deployment and post-deployment conditions that can include waiting for users to manually approve or reject deployments, and checking with other automated systems that specific conditions are met. In addition, teams can configure manual validations to pause the deployment pipeline and prompt users to carry out manual tasks then resume or reject the deployment.
The following diagram illustrates the release pipeline workflow.
By using gates, approvals, and manual intervention you can take full control of your releases to meet a wide range of deployment requirements. Typical scenarios where approvals, gates, and manual intervention are useful include the following.
|Scenario||Feature(s) to use|
|A user must manually validate the change request and approve the deployment to a certain stage.||Pre-deployment approvals|
|A user must manually sign out after deployment before the release is triggered to other stages.||Post-deployment approvals|
|A team wants to ensure there are no active issues in the work item or problem management system before deploying a build to a stage.||Pre-deployment gates|
|A team wants to ensure there are no reported incidents after deployment, before triggering a release.||Post-deployment gates|
|After deployment, a team wants to wait for a specified time before prompting users to sign out.||Post-deployment gates and post-deployment approvals|
|During deployment, a user must manually follow specific instructions and then resume the deployment.||Manual Intervention or Manual Validation|
|During deployment, a team wants to prompt users to enter a value for a parameter used by the deployment tasks, or allow users to edit the release.||Manual Intervention or Manual Validation|
|During deployment, a team wants to wait for monitoring or information portals to detect any active incidents, before continuing with other deployment jobs.||Planned|
You can combine all three techniques within a release pipeline to fully achieve your own deployment requirements.
In addition, you can install an extension that integrates with ServiceNow to help you control and manage your deployments through Service Management methodologies such as ITIL. For more information, see Integrate with ServiceNow change management.
The time delay before pre-deployment gates are executed is capped at 48 hours. If you need to delay the overall launch of your gates instead, it is recommended to use a delay task in your release pipeline.
# Delay further execution of a workflow by a fixed time pool: server steps: - task: Delay@1 displayName: 'Delay by 5 minutes' inputs: delayForMinutes: 5
- Release deployment control using approvals
- Release deployment control using gates
- Configure a manual intervention
- Add stages, dependencies, & conditions
- Release triggers
- Releases in Azure Pipelines