Triggers, Approvals and Release Gates. Once you have defined different types of stages, next you need to consider how the package (a versioned set of artifacts) will be moved through the stages. To release the package from one stage to the next, we can use triggers. There are different types of triggers we can use: Continuous deployment Triggers, Scheduled Triggers, Manual Triggers.

Here is a screenshot of the visual representation of the Azure DevOps Release pipeline. The artifacts are in green, pre-deployment conditions, triggers, and approvals are in purple, and post-deployment approvals are in orange. Scheduled release triggers occur as we would expect with a scheduled task. You can add multiple schedules to one trigger. For instance, perhaps you want to refresh your test environment each night with the code that's currently in development.

Artifact Push/Pull Triggers. We can trigger a release based on the source control actions. Here we have a simple Git project showing push and pull actions. In our pipeline, we can create triggers that initiate a new release based on the action of a Git push or the merging of a pull request.

Stage triggers help move and deploy the artifacts through the various stages of a release. This can be after the release, after a stage, or we can create them as manual triggers requiring user interaction. There are additional options such as auto-deploy triggers. You can base these on post-deployment conditions or a particular event. We can also add approvals. Approvals can give you additional control over the start or completion of a deployment pipeline. Each stage has a pre-deployment and post-deployment condition. One of these conditions can include waiting for users to manually approve or reject a deployment. There are various options around this and you can configure the pipeline to continue with the deployment if no response is received during a period of time.

You can enable gates at the start of a stage, in the pre-deployment conditions, or at the end of a stage in the post-deployment, or both. There are a few types of gates available out of the box as we can see here: Azure Machine Learning, Check Azure Policy, Invoke Azure functions, REST API, Query Azure Monitor alerts, or Query work items. You can add more than one test to a gate, you can add additional tests found on the marketplace or even create your own.

An example of a release gate could be a test that the website responds to a query in a certain amount of time and that there are currently no open issues or bugs against this version of the website. Once you have your tests configured, you have to define the evaluation criteria that define whether or not a gate is marked pass or fail. This includes the time between the re-evaluation of a gate or the sample interval and the timeout after which a gate will fail. 

Here are two examples from the Microsoft documentation. The following diagram illustrates the flow of a gate evaluation where, after the initial stabilization delay period and three sampling intervals, the deployment is approved. We can see from the history that the first gate failed twice and was finally approved when all three gates passed. The next diagram illustrates the flow of a gate evaluation where, after the initial stabilization delay period, not all gates have succeeded at the sampling interval. In this case, after a timeout period expires, the deployment is rejected. We can see gate one failed twice while gate two was passing and then gate one passed and gate two failed. Not all three gates succeeded at the same time.