Azure Pipelines YAML allows us to create PaC (Pipeline as Code) to build and deploy applications to multiple stages e.g. The current setup we have uses a YAML based Azure Pipeline to build a couple of ASP.NET Core web applications. If you want to check that the settings file correctly transformed you can add a simple PowerShell task to output the file contents. I’ve also added a variable “vmWindowsImageName” as for this job I am going to use a windows image. We have designed a pipeline config which will trigger the builds for commits to master, dev & release/* branches and also or pull request to master branch. Note line 33 of the gist, the $(environment) variable is being pulled from the variable group we created earlier in the article which we specified as the variable group to use for the job. Once, I complete that, I will open Azure DevOps and navigate to the Azure pipeline. To demonstrate this process I will cover the following: This article assumes that you are familiar with building YAML pipelines in Azure DevOps Pipelines. Being able to control the full application deployment flow this way is very powerful and allows the whole team to understand how their application is built and deployed. You will need to replace my subscription Id with yours (I have used a build variable here), replace the resource group names with the ones you have created, and replace the azure service connections. There are few things to note in this template, firstly that we are deploying to a linux container so the website configuration is a little different to normal. Fortunately Azure Pipelines YAML includes Templates for variables, jobs, steps and stages to handle this. The test project is .NET Core 3.1 so I will use the DotNetCoreCLI tasks to restore packages and build the tests. You may have noticed in the pipeline that I used “Jobs” and created a single job, this could be seen as unnecessary, but now I am going to add another job that will run in parallel with the Build Job. We will refer other templates from here. Required fields are marked *. Copy the below code in to pipeline YAML file: Now that we have our artifacts, we are going to create the next stage – Deploy to Dev. 2: Classic pipeline in the visual designer. Within this stage, we are going to use a special type of job instead of a stage called a deployment job. Alright, let's see now how to achieve the same with the Multistage YAML Pipelines. There are a few things to note. Adding these appSettings will setup the connection. The Microsoft Docs have a lot of information about different strategies, for this I will use the ‘runonce’ strategy as the other strategies are not supported here. Saving the pipeline should trigger the build. Open Pipelines and then again pipelines in the menu on the left. Once the app is deployed I can then run the UI tests, but first I’ll need to add a FileTranform task to make sure my settings file has the correct URL configured to run the tests against. Click the three dots icon as highlighted below to view the “Approvals and checks” menu item: Within this menu item there are multiple options from controlling which branches can deploy to the environment to triggering an Azure Function, we are going to select the “Approvals” menu item: On the next screen that appears you can then configure who the approvers are. YAML Pipelines There are 2 ways to schedule a YAML Pipeline: using the settings UI and using the YAML syntax. On the following screen asking where your code is select your repository location. There are also a couple of settings that aren’t really documented in the Microsoft Docs to configure the app settings to connect to the ACR to retrieve the image. Note: if you start from a repository without manifests and azure-pipelines.yaml, the pipeline build wizard will propose Deploy to Azure Kubernetes Service.The wizard that follows will ask you some questions but in the end you will end up with a configured environment, the necessary service connections to AKS and ACR and even a service.yaml and deployment.yaml with the bare minimum … For example, if you accidentally added a tab character to your YAML code, you receive one of the following, unhelpful, two errors (depending on where your tab appeared in the YAML): 1. As this will be a multistage pipeline I will create the first Stage to build and push the image. Now that we have configured the environments, the next stage is to add variable groups. Analytics cookies. Initially, we ran into a number of errors that were unhelpful and difficult to troubleshoot. Alex Arif reported May 14, 2019 at 02:15 AM . Now the pipeline builds and publishes the necessary artifacts to the pipeline and the ACR, I can now add a new stage to deploy the application. Again you can verify this by viewing the resources in the Azure Subscription, and navigating to the deployed site: As you can see it is fairly easy to add more stages to deploy to other environments including UAT and Production, and how easy it is to have dependencies between stages. Viewing the summary screen you should now see three stages with the build stage triggered as shown below: After a few minutes the build stage and Deploy to Dev should completed, and you should see that the Deploy to QA stage is awaiting approval before deploying: And now a task to run the UI tests, for this I will use the VSTest task to run and publish the test results to the Azure Pipeline UI. Do the same for QA inserting qa as the name instead of dev: Once both environments have been created, click the Environments menu item again and you should see the below: As mentioned above when describing the stages, we stated that the QA environment requires approval before the application is deployed – Clicking the qa environment will take you through to a screen where this can be configured. Here as mentioned above you could also link to Azure Key Vault, or add as many parameters including secret parameters as you like. The variables parameter at lines 8 and 9 of the gist below – This should match the variable group you created above for the dev variables. There are a few more settings for approvals, how many need to approve, approval timeout, etc. Click save once complete. Changes can be approved, tracked and are visible to everyone instead of a change via a UI that goes unnoticed and difficult to track if there is a problem caused by a change. You can find all the code used and the deployment files on my GitHub. As the sample stands now we have a single Pipeline that builds two different ASP.NET Core web applications in a single job using the following YAML. Display diff when commiting a pipeline change. Multi-Stage YAML pipeline for manual intervention. This is the equivalent to this classic pipeline in the visual designer: Fig. Now everything is configured, I can create the initial YAML to build and push the application to an ACR. Build/Release pipelines vs. a multi-stage pipeline, enabling the preview feature (it's still in preview at the time of writing) and an overview of the structure of the file. I will also use this space to post things that might be of interest to others in the development world! on Multi-Stage Pipelines using YAML for Continuous Delivery – Azure DevOps, displayName: 'Install the angular cli globally', Techniques for automating SQL Database releases using Azure DevOps. Variables are read from templates which is another yaml file in the same directory. Give the approval to the pipeline and wait to see. In this post, we are going to cover using YAML with Azure DevOps for multi-stage deployments. At the bottom of the screen is where you can add your variables. It should trigger a build pipeline that will run the unit test cases, code analysis and deploys it to dev/QA environments. Windows Azure Storage Emulator – Error: Unable to start the storage emulator. I am going to be using the Azure Repos Git menu option for this post. The full pipeline with the template now looks like: Now the pipeline has ran, let’s check the results. The template file will look like: Now I can update the ‘Staging’ stage to use the new template. This is important as these will be the variables that are used within the jobs. Azure DevOps. * Approvals not being in YAML is a change in our design/approach based on the feedbacks. When you add two or more users, extra options appear that allow you to set if all are required for approval, if one person can approve for all, and if a particular order needs to be followed. As this is a container application I will use the AzureWebAppContainer task. So I need to add some tasks to build my UI tests. For demo purposes, I have called mine VariableGroup-dev. First the pipeline will trigger on a push to master. The list items in trigger section enables the triggering criteria — Master/Release branch changes. Create a pipeline. In my previous post, I have explained step by step approach to create azure automation account and runbook. I have a multi-stage pipeline for my Terraform code. Use NuGet 4.4.1) is part of an agent job (here Agent job 1). In Pipelines a job is something that a single agent takes and runs. if other pipelines already exist in this project, you can find the same button at the top right. Now I have the image uploaded to the ACR, I need to define the Azure Web App that I will be deploying to. Please see the screenshot below: We need to do the same for the QA environment, this time setting the Environment variable to qa. https://app-multistagepipeline-dev.azurewebsites.net/, Stage 1 – Build – This will build an Angular application and an ARM template project, producing the artifacts which will be used by Stage 2, and then Stage 3, Stage 2 – Deploy to Dev – This will take the artifacts from Stage 1 and deploy the infrastructure to an Azure Dev environment followed by the Angular application. In Azure Pipelines , open the Releases tab. but I am not going to go into detail about them. In this post I will explain how multi-stage pipelines works and naming conventions to create environment. YAML build pipeline enables developer to save pipeline as code, however multi-stage YAML pipelines provides ability to scale your pipeline to support both continuous integration (CI) and continuous deployment (CD). Your email address will not be published. Enabling continuous deployment trigger will instruct the pipeline to automatically create a new release every time a new build is available. Finally, our project, from the source code, to the build to the release, can be stored as infrastructure as code.… There have been a lot of changes added, so let’s see the full pipeline so far: This is great but I would guess most of us don’t just have one environment that we need to deploy to and will need at least another one and maybe a manual intervention step too. You have an Azure Service Connection configured in Azure DevOps that can deploy to your resource groups in your Azure Subscription, You have pulled the code from the repository, The environment parameter at line 7 of the gist below – This should match what you named your dev environment. Whilst this approach would work, it would introduce a maintenance overhead we don’t want. Once complete you should see the screen below showing: We can navigate to our Azure Subscription and see the resources created and navigate to https://app-multistagepipeline-dev.azurewebsites.net/ to view the deployed Angular app as shown below: The final stage is deploying to QA. For this I will use an ARM (Azure Resource Manager) template. Adding a PublishBuildArtifacts task to the build steps will perform the artifact creation. Stage 3 – Deploy to QA – This will take the artifact from Stage 1 and deploy the infrastructure to an Azure QA environment followed by the Angular Application after Stage 2 is successful and when manually approved by a user. This blog is going to be used to share solutions to problems faced whilst crafting software to both help me remember how I solved something if it crops up again, and to hopefully help others in the same situation. The pipeline defined above sets up the environment name of release on the first two stages, and the rest stages use their own environment name. This is just a basic pipeline, let’s transform it to a multistage pipeline: trigger: - master pool: vmImage: 'ubuntu-latest' stages: - stage: Build - stage: tst_deploy - stage: uat_deploy - stage: prd_deploy As you can see, there is a stages section added with some defined stages, for example a build stage, and some deployment stages. Standard-CI-CD-Pipeline.yaml –This is the main yaml file. Navigate to Azure DevOps, and click the Environments menu item under the Pipelines menu icon: On the screen that appears click the “Create environment” button. YAML Multistage Pipelines - Link workitems to deployments. I learnt to trigger Azure DevOps build pipeline form Azure Automation runbook. For simplicity I have used the default ASP.NET Core Web Application in Visual Studio 2019 with Docker Support enabled for Linux to create the web application. Defining multiple deployment stages. I can no longer Edit Pipeline from the log view window. With the job and strategy configured, I can now add the first step to execute the ARM template and create the Web App. The YAML file usually stored in the same repository with the application code. I am going to put myself in for now, however, you can add as many users as you like. We will start by adding these environments in Azure DevOps. To create another environment I could just copy and paste the ‘Staging’ stage, rename it and update the variables. This is important as all deployment history will be recorded against the environment, and as you will see later when creating the stage to deploy to test, this is also used to determine if approvals are required. In the jobs section there are two important parameters to highlight: Next up we are going to add two tasks, one to deploy the ARM template and another to deploy the Angular site. But we need to be careful, because scheduled triggers defined using the pipeline settings UI take precedence over YAML ones. After creating a new pipeline in Azure Pipelines, I need to configure the Azure and ACR connection variables in the pipeline UI.