Here are the steps to create a multi stage YAML pipeline

) You need to trigger the multi stage pipeline experience in Azure Devops to use this feature.

2.) Create a repository, have some code in it and create a file in the root of your repository, called azure-pipelines.yml

3.) Enter the following constructs in it. We create a build stage now.

You should know that the steps will vary, according to the code you deploy. The important things in this code is

the word “stage” — This tells Azure Devops to create a stage. The stage which we have created is called the Build stage, this stage will have all the build tasks. We will create the DeployToDev and DeployToTest stage in the next steps.

— This tells Azure Devops to create a stage. The stage which we have created is called the Build stage, this stage will have all the build tasks. We will create the DeployToDev and DeployToTest stage in the next steps. the task PublishPipelineArtifact — This task should be used , so that the artifacts created in one stage, can be subsequently used in another stage. We need to use the build artifacts created in Build Stage in the subsequent stages, so that we can deploy them to different environments

4.) Now we create the DeployToDev stage:

Here, the important points are:

The construct “dependsOn” — The DeploytoDev stage will only depend on the previous stage, which is the Build stage. If the Build Stage fails, this stage will be skipped. You can also specify conditions, for example: condition: and(succeeded(), eq(variables[‘build.sourceBranch’], ‘refs/heads/master’)). This condition will be useful for stages like DeployToQA, where you don’t want commits form your development branch to go to QA and only want commits from the master branch. You can specify many other custom conditions, here is the link for your reference: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/stages?view=azure-devops&tabs=yaml

— The DeploytoDev stage will only depend on the previous stage, which is the Build stage. If the Build Stage fails, this stage will be skipped. You can also specify conditions, for example: condition: This condition will be useful for stages like DeployToQA, where you don’t want commits form your development branch to go to QA and only want commits from the master branch. You can specify many other custom conditions, here is the link for your reference: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/stages?view=azure-devops&tabs=yaml the word environment — This creates an environment in AzureDevops automatically, if its not created before. Environment helps you track the deployments done on each env. It also helps to keep track of resources, commits and also specify approvals. We will discuss approvals in the next steps.

— This creates an environment in AzureDevops automatically, if its not created before. Environment helps you track the deployments done on each env. It also helps to keep track of resources, commits and also specify approvals. We will discuss approvals in the next steps. the word strategy — Default one is runOnce, but there are more deployment strategies coming up soon, like Canary, Rolling and blue green. Have alook here: https://devblogs.microsoft.com/devops/whats-new-with-azure-pipelines/

Default one is runOnce, but there are more deployment strategies coming up soon, like Canary, Rolling and blue green. Have alook here: https://devblogs.microsoft.com/devops/whats-new-with-azure-pipelines/ the task DownloadPipelineArtifact — This downloads the artifact of the previous stage in your current stage, using the artifact keyword as the identifier. This is important as we need to use the build artifacts in subsequent stages for deployment.

In the same way, you create the second stage called DeployToTest, the only difference would be that DeployToTest would depend on DeployToDev.

5.) Click on new Pipeline in the Pipelines section in AzureDevops:

6.) Select Azure Repos Git which supports YAML pipeline

7.) Select your repository, select existing azure Yaml file and then give the path of the Yaml file:

8.) Check your YAML file, you can also review and change your YAML pipeline here. The editor recognizes the YAML file and gives you Intellisense on it. After you check your YAML file, click Run

9.) The YAML parser will recognize the stages and create a simplistic GUI like below:

10.) After all the stages are completed, you can go under Environment section. You will see 2 env’s created, Dev and Test. If you remember, this was the same name which we had used in the environment keyword, while we were defining stages.

If you click any environment, you will see the complete list of deployments done on that stage. This helps in keeping track of resources in each environment.

Another amazing feature is approvals, every environment can have a list of approvers , which will approve deployment. Currently, all approvers must approve, and Microsoft is trying to work more on different kinds of approvals and also creating pre and post deployment gates at each stage , like we have for Releases.

To specify approvals, click on Check under the Test env

Enter the approver name, if you specify many people, all have to approve, if you specify a group, only one person in that group should approve.

Put approvers

11.) If you run the pipeline again, at the DeployToTest stage, it will wait for approvals.

Waiting for approvals

Currently, the approvers don’t get any mail notification, but Microsoft is actively working on getting this feature ready by November.

One more point, now because you have set the pipeline, any commits on the master branch, will automatically trigger the pipeline to run again, you can stop this feature by turning off the Continuous integration feature on the branch.