Release approvals and gates overview
Azure Pipelines | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015
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.
Approvals and gates give you additional control over the start and completion 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 until specific conditions are verified. In addition, you can configure a manual intervention to pause the deployment pipeline and prompt users to carry out manual tasks, then resume or reject the deployment.
At present, gates are available only in Azure Pipelines.
The following diagram shows how these features are combined in a stage of a release pipeline.
By using approvals, gates, 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|
|Some users must manually validate the change request and approve the deployment to a stage.||Pre-deployment approvals|
|Some users must manually sign out from the app after deployment before the release is promoted to other stages.||Post-deployment approvals|
|You want 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|
|You want to ensure there are no incidents from the monitoring or incident management system for the app after it's been deployed, before promoting the release.||Post-deployment gates|
|After deployment, you want to wait for a specified time before prompting some users for a manual sign out.||Post-deployment gates and post-deployment approvals|
|During the deployment pipeline, a user must manually follow specific instructions and then resume the deployment.||Manual Intervention|
|During the deployment pipeline, you want to prompt the user to enter a value for a parameter used by the deployment tasks, or allow the user to edit the details of this release.||Manual Intervention|
|During the deployment pipeline, you want 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 though Service Management methodologies such as ITIL. For more information, see Release deployment control using ServiceNow.
The time delay before the 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 # Delay further execution of a workflow by a fixed time jobs: - job: RunsOnServer pool: Server steps: - task: Delay@1 inputs: delayForMinutes: '0'
- Manual intervention
- ServiceNow release and deployment control
- Release pipelines and releases
- Video: Deploy quicker and safer with gates in Azure Pipelines
- Configure your release pipelines for safe deployments