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.