Tallan Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

Azure DevOps Pipelines Deployment Controls

Azure DevOps is a work item tracking, source control, and release management solution provided by Microsoft. It is the cloud-based evolution of Team Foundation Server. If you don’t have a DevOps account, you can get one for free at https://azure.microsoft.com/en-us/services/devops/.

Release Pipelines is a powerful feature of DevOps that allows you to create pipelines to deploy your builds out to your server environments. Let’s say that you are creating a Release Pipeline for your website and you have a separate environment for Dev and Production, both hosted on Azure App Services. When you check code in, you want it to be deployed to your Dev environment automatically through Continuous Integration. This is easily configurable through the Release Pipeline interface.

What about your Production environment though? You want to use the same build artifacts for your Dev and Production environments, so it makes sense to put both environments in the same Release Pipeline. But you want to validate the build in the Dev environment before you release it to Production. DevOps provides two features to implement this workflow: Pre-deployment approvals and Gates.

Pre-Deployment Approvals

Pre-deployment approvals is the more straightforward of the two options and is very easy to implement. The premise behind pre-deployment approvals is that there is a user or set of users that are given permission to “approve” a stage of the Release Pipeline. The stage will wait in a pending state until all of the designated users give their approval. Once all users give their approval, DevOps will go ahead and release the build out to the Production environment.

The great thing about using pre-deployment approvals is that the approvers can go in and manually verify whatever they need to in the Dev environment. They can check to make sure that all regression tests have passed, that there are no new bugs resulting from the build, or that the release has been approved internally for Production.

This power comes at a price however – the approvers need to perform all of these actions manually, which leaves room for error and can be time consuming. Despite this, pre-deployment approvals will be the first “release control” measure that most organizations choose to implement simply because they are so easy to set up.

Gates

Gates are DevOps’s answer to the question “How do I automatically check that my new build is production-ready before deploying it to production?” Gates can take over some of the manual work that approvers need to perform before they certify that a release is ready for Production. Gates are evaluated in parallel before the release is allowed to proceed. Gates can be run either before or after the required approvals are made. Gates are re-evaluated by default every 15 minutes, and all gates must evaluate successfully before the release can proceed. After a configurable amount of time without a quorum of successes, the release itself will fail.

When adding gates to a Release Pipeline you have several options for how they can collect the data they need to evaluate. These are the options currently offered for gates, along with the descriptions that Microsoft provides:

  • Invoke Azure Function – Invoke an Azure Function as a part of your pipeline.
  • Invoke REST API – Invoke a REST API as a part of your pipeline.
  • Query Classic Azure Monitor Alerts – Observe the configured classic Azure monitor rules for active alerts.
  • Query Work Items – Executes a work item query and checks for the number of items returned.
  • Security and compliance assessment (Currently in preview) – Security and compliance assessment with Azure policies on resources that belong to the resource group and Azure subscription

These options provide a great deal of flexibility for a variety of scenarios in which you might want to use gates. For example, if you want to check to make sure that no open bugs are logged against the build in question, you can create a custom work item query to find those bugs and then use the Query Work Items gate. Or, if you want to query for information in another system you can write an Azure Function to retrieve the information or access a REST API that the system exposes.

Example

As an example, we will explore the scenario where we have an external release approval system that we want to tie into the Release Pipeline. To represent the release approval system, I have created an Azure Function that returns True 50% of the time and False 50% of the time. An actual Function or API call can perform whatever logic you need it to, but in this case, we will use a coin flip because the actual logic performed doesn’t matter to the gate.

#r "Newtonsoft.Json"

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;

private static Random randomGen = new Random();

public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
    return new OkObjectResult(randomGen.Next() % 2 == 0);
}

The code used in the Azure Function.

Once the function is created, we can proceed to the Pipeline view for our Release. This pipeline has a Dev stage and a Prod stage. The Dev stage is configured to release automatically when a new build is completed. Our goal is to make the Prod stage wait until our external release approval system has approved the release and an admin has approved the release inside DevOps.

Release Pipeline View

To do this we click the “Pre-deployment conditions” button at the left of the Prod stage. On this screen, we can see the various options available. First, let’s look at the Pre-deployment approvals.

Pre-Deployment Conditions

The only thing we need to do here is to add in the approver or group of approvers who we want to be able to approve the release. We are using the built-in pre-deployment approvals even though we also have the external release approval system because they give us an easy way to decide when we want the release to be performed. Oftentimes releases can only be performed after business hours. Pre-deployment approvals can be used to easily control the actual timing of the release.

The next step is to configure the gates to check with the external release approval system. We can set a delay before they start processing in order to give the approvers time to go into the external system. We will choose the “Invoke Azure Function” option to add our Function.

Gates

Let’s take a look at the top portion of the configuration. Here we can enter in the Azure Function URL, Function key, and HTTP method. The Function URL is the name of your Function App appended by the API route. Azure uses the Key to limit access to the Function so that only authorized users can call it. You can find both of these values in the Azure Portal page for your Function.

Azure Function

Now that we have configured the connection to the Function, we need to define what we consider success to be. Under the Advanced tab, there is an option for Success Criteria. By default, the gate will pass if there is any success response (200-level) from the Function. Our function returns true or false in the body, so we need to define a Success Criteria. We simply check if the root of the response is true with the criteria “eq(root, true)”.

Success Criteria

Finally, under Evaluation options we can set the time between re-evaluations, the length of time the gates will retry for, and which order Azure will evaluate the gates and approvals in.

Evaluation Options

Since we selected the “On successful gates, ask for approvals” option, the gates will evaluate first. You can see that the first evaluation at 2:53 PM failed, so DevOps waited five minutes and evaluated the gate again. It succeeded the second time, so the gate evaluation phase of the release has completed and DevOps is now waiting for the Approver to approve the release.

Gate Success

Clicking on the Approve button as the approver allows the deployment to proceed. Additionally, the approver can defer the deployment until a later time.

Pending Approval

Now that the gates have succeeded and the approvals have been made, the release proceeds.

Completed Release

By now, it should be clear that pre-deployment approvals and gates are a powerful feature of DevOps Pipelines that you should be using whenever you need control over your environment deployments. The example above is a simple use case, but you can expand on the ideas behind it in order to develop a robust release approval system for your organization.  


Click Here to learn more about Tallan or see us in person at one of many Events!

Share this post:

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

\\\