Are Multi-Stage YAML Pipelines in Azure DevOps Ready for Prime Time?

Microsoft recently announced that Multi-Stage YAML pipelines has gone GA (General Availability) and this has generated a lot of interest in YAML based pipelines replacing the UI based ones. The last time I looked at YAML pipelines, there were quite a few limitations for releases that kept us from fully switching over. Over the last few weeks, I did some live coding experiments on Twitch, performed a thorough comparison of features, and reviewed it with our teams to come to the conclusion that the Multi-Stages YAML pipelines are ready for prime time. You should start investigating and looking into the new features and additional functionality only available in the YAML pipelines.

Back in 2015, Microsoft updated the build system to the web based, cross platform system that is today. The build system is made up of two key parts. First is builds that performs activities that compile, verify quality of the code, and package the application into an artifact so it is ready to deploy and release. The two common types of builds that are performed here are PR builds and CI builds. Releases manage the orchestration of artifacts throughout the environment performing activities such as deployments, automated testing, approval gates, and more. Microsoft has renamed these builds to Classic UI builds.

A Multi-Stage YAML Pipeline represents the entire pipeline from CI to the deployments to each environment as a YAML code file. The YAML file essentially replaces what both the Builds and Releases accomplishes. This is built on the same platform as the Classic UI builds and releases.

Here is a simplified representation of what a multi-stage YAML Pipeline looks like. Any time you are using code versus an editor, there will be a learning curve. YAML is no different. It is a simple syntax of key value pairs similar to JSON but YAML uses indention instead of brackets.

trigger:

- master

stages:

- stage: CI

jobs:
  - job: Build and Package App
steps:
  - checkout
- Install Node.js
- npm install and build
- publish artifact

- stage: DEV

jobs:
  - deployment: Deploy Web App
    environment: Dev environment
    steps:
     - Provision Web App Infrastructure
     - Deploy Web App

-stage: PROD

jobs:
  - deployment: Deploy Web App
    environment: Prod environment
   steps:
     - Provision Web App Infrastructure
     - Deploy Web App

When authoring YAML pipelines you do get some assistance. Editing in the web and using the Azure Pipelines extension in VSCode provide intellisense and display error indicators if indenting or syntax isn't correct. In addition, when adding tasks as steps, you can use the assistant to find the desired task and help set the appropriate values.

I went through all of the typical activities we perform builds and releases and made sure they were all able to be accomplished with YAML pipelines. All of these activities are available or equivalent functionality is available. Only one feature didn't have a good alternative in YAML pipelines is deployment gates. If you are using these, you probably will want to still with the releases for now or handle it with custom decorators. There are a few older technologies like TFVC and Subversion that are not supported. This link provides a nice feature comparison list.

YAML pipelines offer some advantages over the classic UI builds and releases. First, the YAML file is code and lives with the application code so when you branch your code, you branch your YAML pipeline file. This allows you to modify the build in your branch without affecting other branches. Also, with smaller applications and microservices able to be deployed independently, the overhead of having a PR, CI, and Release for each deployable because harder to manage. There's also a few new features in YAML pipelines that make them more compelling. Features like templates for making pipelines and utilizing environments to separate compliance and approvals from the pipelines.

If you haven't started looking into YAML pipelines, now that it is GA and at feature parity with classic UI pipelines, it is a great time to start. Microsoft Learn has several nice hands on labs for getting started. Microsoft Learn - Create a multistage pipeline by using Azure Pipelines.