Azure DevOps Pipelines – Multi-Stage Pipelines and YAML for Continuous Delivery
In this post, App Dev Manager Taylor O’Malley gives a walkthrough of Multi-Stage YAML pipelines for CI/CD.
Azure DevOps previously added capabilities for YAML based pipelines to the portion of the suite known as Azure Pipelines. Continuous Integration and Continuous Delivery strategies help teams to increase efficiency and drive quality, and YAML based pipelines layer additional capabilities, enabling developers to treat these CI/CD Pipelines as code. There are great tools and resources for understanding how to Convert Classic Pipelines to YAML, and there are more features being rapidly developed for Azure DevOps and YAML. One of these features is Multi-Stage Pipelines, which allows you to configure your pipelines to do CI, CD or both in your YAML pipeline.
I experimented recently with Multi-Stage Pipelines, with a few specific questions in mind:
- Can I easily tell what stage of the pipeline my deployment is currently in?
- Can I redeploy an older build to a stage?
- Can I set approvals for different stages?
Note: Multi-stage Pipelines are currently available as a preview feature. See “Enable Preview Features” for more information about enabling this experience.
Multi-Stage Pipeline YAML
As mentioned above, there are many options for creating your first YAML pipeline. The YAML reference schema was particularly helpful for configuring my first Multi-stage pipeline. Stages are a collection of related jobs, such as the “Build”, “Test”, or “Deploy.” I used stages to build my application, and then target a deployment to my Dev environment, and then my QA environment.
The first thing I wanted to see was whether I could easily tell what stage of the pipeline my deployment was currently in. There are two places this appears:
In the “Runs” tab for my Pipeline, we can see that in the most recent run, my first two stages were successful, and my third stage is in the “Waiting” status.
If we drill into this specific run, on the summary page for this pipeline run, we can see more specifics about each stage. My build and deployment to Dev were complete, and my QA deployment is waiting for one check to be run.
Next, I wanted to see what the experience would be like to redeploy a previous build to an environment. My deployment to Dev was completed successfully, however I need to deploy yesterday’s latest build to the dev environment. After navigating to the pipeline run that contains the build I want to deploy, in the “Dev Deployment” Stage, after selecting the drop down arrow in the top right corner, I now see the option to “Rerun stage” which allows me to redeploy the previous build to my Dev environment.
Lastly, I wanted to see if I could configure approvals before a deployment to a specific stage. Currently, manual approval checks are supported on environments. Using Environments in my YAML pipeline, I was able to add a manual approval check to ensure the deployment to the environment only happened when the designated user reviewed the changes being deployed. Note, this was not something I configured directly in the YAML file, however in the YAML file I added the environments keyword, and defined the approval in the Environment. This is described in more detail in this Define Approvals and Checks article. When the pipeline gets to my “Dev Deployment” stage, we can see that it is in the “Waiting” status, and by the message displayed above, it is awaiting approval.
After approving the deployment, not only does my stage proceed to run, but it also records the deployment of this build in the history of my Dev Environment, providing nice deployment history, and traceability for this environment.
Note: Environments provide several additional capabilities not highlighted here, specifically serving as a collection of resources targeted by deployments including Kubernetes, Azure web apps, virtual machines, and databases. Additional information on environments can be found here.
YAML Pipelines enable you to store your pipeline as code, and Multi-stage YAML pipelines provide the ability to scale this to CI, CD, or the combination of the two. Don’t hesitate to experiment with converting your CI/CD pipelines to YAML!