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 firstname.lastname@example.org.
- 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
In some GitHub projects, you may have noticed these badges. The badges can define the states and different aspects of a project. These tags can be generated by Azure DevOps. This can help generate a view of what state various parts of the project are in, regarding build, deployments, release or even compliance.
We've already looked at release gates. If we explore this idea further, we can use release gates for two different purposes. The type we discussed earlier was using gates for automatic approval of a release. We can also use a release gate as a quality check. This could mean we create a query against work items that are looking for any outstanding bugs, issues, incidents against this release version. We could also do it for security scanning the code base or scanning artifacts like containers for security compliance.
Automating tests is another challenge when we start looking at incorporating it into continuous delivery pipelines. To automate testing, this chart has been designed and can help us define tests into four quadrants that helps us define what test we can automate. Tests in quadrant one are designed at the lowest level to test specific functionality, generally allowing them to be automated easier than some other tests. Quadrant four focuses on tests that require tooling to help, things like load testing, measuring performance, or security analysis. Tests in quadrant two and three move into the more complicated tests that are generally harder to automate or that simply require user interaction.
Documentation can have a number of different purposes from design, tracking work items, logging issues and bugs, installation, configuration, through to product operational manuals. There are a variety of approaches to this. One solution might not fit all use cases and you may need to use a combination. When we introduce more automation using release pipelines and increase the number of changes in an environment, we need to ensure that supporting documentation stays in sync.
Documentation can describe the changes that are present and being released into each environment and also needs to be in step with the product or environment changes, including a manual of how these new features and functionalities work. Manuals or documentation that we release together with the product should be treated as source code also.
A common method is using text files sometimes written using markdown syntax that are stored in the same directory or repository as the code. Another option is to create a new repository like a wiki. There are also wikis in Azure DevOps. In addition, we can use services like SharePoint or third-party solutions like Confluence by Atlassian. Another option is using work items to store and capture release notes. Depending on how you track your tasks, you could have bugs, tasks, user stories or other items which you can extract data from a particular field to cobble together a release notes text block allowing the task of extracting this text to be fully automated.
Now that we have covered ensuring the quality of a release pipeline, let's return to the lab and look at cloning and finishing off our lab environment.
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.