One of the announcements made by the Azure DevOps team that has gone under the radar is that of the ability to use YAML Pipelines for deployments. This functionality is intended to eventually replace the existing “Classic Release” process. For those that are uncertain the Classic Release is the UI editor in Azure DevOps under releases.

Update: Check out my presentation to the Omaha Azure User Group to see these action!

If you aren’t sure that YAML Pipelines will replace release look at the Azure DevOps Roadmap. Do you see things for Releases or Pipelines? Further more if you look for what’s planned there are certain features like “Conversion from classic build pipelines to YAML pipelines”. In addition have you noticed on the release tasks there is now an “Export YAML” feature?

What this means for those that are experienced developer in Azure DevOps is the language, YAML, used today for the Build process will also incorporate the release/deployment phase. For any question on what you can accomplish with using Pipelines check Microsoft’s site. Some of the key features includes gates used for “releasing” your code to the next environment as well as an easier way to run your deployments in parallel.

In addition to this one of the biggest added benefits is that the steps used to deploy code are now under source control. Since the deployment is defined as YAML code then this code will be checked into your source repositories and easily integrated into any existing CI/CD processes. This means that such things as required approvals before merging code can pertain to deployments now. Since this is under source control support for branching and merging are supported as well as any types of triggers that would normally be defined in a build process.

Another benefit is the ability to use templates. If we are able to “templatize” our deployment steps then we have the ability to run execution steps for DEV/TST/PRD are all the exact same and only need to be entered once. This is in stark contrast to Classic Releases where we’d need to copy a stage and manual update the tasks. When we are doing this we are always introducing the possibility of drift due to manual intervention/human error.

One might be asking can’t we accomplish this same feat through Task Templates. The answer to this is yes but with limitations. Task Templates are all or nothing. We can’t define a specific task like say a Yarn install and then make that Yarn Install template task be part of additional releases. We’d need to incorporate our Yarn Install task in each template we make. Another downside with Task Templates is they are not easily exportable from one Azure DevOps instance to the next. Yes there is the export button; however, exporting and importing across Azure DevOps organizations is problematic. With YAML Pipelines we have the ability just to import our YAML file and if written correctly they are Organization agnostic if properly configured using variable files.

This leads us to the next benefit of using YAML Pipelines, the ability to use variables. Variables are supported at each level stage, job, task which makes things much easier to scope variable usage. We can store our necessary variables in a separate variable YAML file. In addition variables can be stored in an Azure DevOps variable group for security purposes.

Another ability is the support for multi-repositories when running a release. This leads to the ability of our deployments being decentralized. In larger organizations we can do the heavy lifting and create template tasks that adhere to an organizations best practice and store them in a shared repository. Imagine all my code scanning or that necessary email task audit requires is already written for me in a template and all I need to do is call said template and pass in a value or two and that’s it. We no longer have to worry if we included everything or how this will be maintained. If an update is required to a shared template we can make the update and everyone will receive. (And thanks to branching/merging support, we can make these template changes in a separate branch and test for validation).

This is just a jumping point as I will have a follow up post examining how Multi-Sage YAML Pipelines can be used in a micro-services environment. Imagine all I have to pass in is the environment and my templates do the rest….that’s exactly what YAML Pipelines can accomplish through the use of templates and variables.

For more examples of how to leverage this be sure to check out my post on Multi-Stage YAML Pipelines in a Microservice Architecture. Making Life Easier