Implementing Continuous Delivery
The course is part of these learning paths
This course deals with how to implement continuous delivery with the Azure DevOps solution. In particular, we will be exploring how to design different release strategies and some factors you need to consider while setting up release pipelines. This will include looking at release triggers, release gates, and other areas associated with releasing code, including working with different environments. We will also take a look at deployment patterns and how they can be implemented in your release strategy and release pipelines. During this course, we will be using hands-on examples to help work through these concepts and configurations.
If you have any feedback for us about this course, please contact Cloud Academy at email@example.com.
- Design a release strategy
- Set up a release management workflow using Azure DevOps
- Implement an appropriate deployment pattern
- DevOps engineers
- People preparing for Microsoft’s AZ-400 exam
- General knowledge of Azure
- Experience with Git version control, including pushing changes into repositories
- You do not need to know any specific development language
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.
Matthew Quickenden is a motivated Infrastructure Consultant with over 20 years of industry experience supporting Microsoft systems and other Microsoft products and solutions. He works as a technical delivery lead managing resources, understanding and translating customer requirements and expectations into architecture, and building technical solutions. In recent years, Matthew has been focused on helping businesses consume and utilize cloud technologies with a focus on leveraging automation to rapidly deploy and manage cloud resources at scale.