Release gates and approvals overview

TFS 2018

Note

Microsoft Visual Studio Team Foundation Server 2018 and earlier versions have the following differences in naming:

• Pipelines for build and release are called definitions
• Runs are called builds
• Service connections are called service endpoints
• Stages are called environments
• 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.

Note

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.

YAML

# Delay further execution of a workflow by a fixed time
pool: server
steps:
- task: Delay@1
  displayName: 'Delay by 5 minutes'
  inputs:
    delayForMinutes: 5

Classic

1. From your pipeline definition, select the ellipsis button (...), and then select Add an agentless job.

2. In your new agentless job, select the + sign to add a new task.

3. Search for the Delay task. Select Add to add it to your agentless job.

4. Enter the Delay Time in minutes.

5. Select Save & queue when you are done.

Note

The delay task can only be used in an agentless job.

Related articles

• Release deployment control using approvals
• Release deployment control using gates
• Configure a manual intervention
• Add stages, dependencies, & conditions
• Release triggers
• Releases in Azure Pipelines

Next steps

Define approvals and checks Use approvals and gates to control your deployment