1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Implementing Continuous Delivery on Azure

Lab 04: Clones Stages

The course is part of this learning path

AZ-400 Exam Prep: Microsoft Azure DevOps Solutions
Start course
Duration1h 2m


This course deals with how to implement continuous delivery with the Azure DevOps solution. In particular, we will be exploring how to design different release strategies and some factors you need to consider while setting up release pipelines. This will include looking at release triggers, release gates, and other areas associated with releasing code, including working with different environments. We will also take a look at deployment patterns and how they can be implemented in your release strategy and release pipelines. During this course, we will be using hands-on examples to help work through these concepts and configurations.

If you have any feedback for us about this course, please contact Cloud Academy at support@cloudacademy.com.

Learning Objectives

  • Design a release strategy
  • Set up a release management workflow using Azure DevOps
  • Implement an appropriate deployment pattern

Intended Audience

  • DevOps engineers 
  • People preparing for Microsoft’s AZ-400 exam


  • General knowledge of Azure
  • Experience with Git version control, including pushing changes into repositories
  • You do not need to know any specific development language


The next task we want to do is clone the stage tasks. So we're just gonna clone this one and if we go into this task, we're gonna pull this PreProd. We're also gonna change the pre-production conditions, so this one's actually after release, and we enabled the pull request previously on this one, so this is a pull request deployment, so we can turn that on for this particular stage, and we need to apply the artifact filter for html-docs, and this is for the master branch.

We'll close that, and we need to clone the Test environment to be our production, so we're gonna swap this slot with the PreProduction slot. So this is called Production, and we want this to be after the stage PreProd, and for Production, we don't want it to be scheduled, we actually want to get some approvals, so we need a responsible person before we go through. There are other options here around the user can't approve their own request. For our purposes, this is fine.

Next, we'll need to change the variable scope. So at the moment, we've connected VarDev into these other environments we've just created. So we're gonna change the scope of that and untick it for PreProd and Production, and we're going to link ourselves with the VarProd, particular stages, and PreProduction, and Production. So we've now mapped to a different set of parameters to our secondary pipeline.

So let's kick this one off. We're gonna create the release manually and we're gonna say here, select stages for manual trigger, so we're gonna select PreProd, we'll go to the release, and we can see now that the artifact doesn't meet the conditions, but we can deploy this one. Job waiting. So we'll let that go, and in the meantime, we're gonna add some badges to our HTML pages to the... We're gonna add some badges to the code, and if we go into options, under integrations, we can see here, we can say enable the deployment stage badges. Now each one of these is the actual badge for Development, Test, Production, PreProduction, and we can put that into our Visual Studio code.

Let's copy the Development badge, and we'll bring up Visual Studio Code. We're gonna make this change in the markdown file, so let's bring the markdown file back, and put the status at the top. We can see, just used markdown syntax and put in the pasted link from each of the different badges for each of the releases. We can save that and commit that code. And push that into dev branch. Save it first, come into our files section, and we'll look at the html-docs for the dev branch, and look at the markdown syntax, we can see we've got three badges, never deployed, succeeded, succeeded, and I've got a syntax mistake here. Brackets the wrong way around. Go.

So by enabling those deployments, we can now see the different states in our markdown page, in our Github Repo, and we can obviously see that the PreProduction environment we manually kicked off deployed, now we'd like to do one last thing and just test if that pull request will work. So we can do that from within here. If we go to our Branches, we can see we've got the just now and our master branch which hasn't changed. So if we go to our Pull requests, we're gonna create a new pull request, dev into master, Pull trigger test. You can associate different items to see what's changed. In this case, it's gonna push everything we've done; we're just gonna complete the request.

It's important here that for this example, we're not gonna delete the branch, so this is a nondestructive branch change, and complete the merge. If we return to our Pipeline Releases, we can see now we've got the pull request here, merge, and Release-14's been created from the master. So again, we can see the trigger that effects this, we can see this artifact condition hasn't been met because it's not from the dev branch, whereas the artifact condition here has been met.

We still have an existing deployment in the background, so let's go back to... Last deployment is down here. So that's the one we triggered manually. We'll have to wait for these to finish before we can test the release into production. Here we can see that the PreProduction's kicked off. If we look at our Azure portal, at our Resource groups, we can see we've got a new resource group for a production version of this application. So we've got the PreProd slot, the production app. So we can see the PreProd deployment finished, and we're now pending an approval for Matthew. So I can simply approve that task, go for production.

Before we do that, if we go to our webapp and look at the PreProd, and do a browse, we've got a Welcome to DevOps, and we go back to the webapp and our production slot, and browse. There's nothing there. Go for production, Approve. It is now kicked off. We'll give it a few minutes. You see in this case it isn't downloading those artifacts now that we've taken that step out, so initialize the job and then swap the slots. So we see production has succeeded. We refresh this, we have Welcome to DevOps, and our PreProd environment will be blank. So I hope this walkthrough has been helpful and given you a good base to learn some of the other aspects of Azure DevOps.

About the Author

Matthew Quickenden is a motivated Infrastructure Consultant with over 20 years of industry experience supporting Microsoft systems and other Microsoft products and solutions. He works as a technical delivery lead managing resources, understanding and translating customer requirements and expectations into architecture, and building technical solutions. In recent years, Matthew has been focused on helping businesses consume and utilize cloud technologies with a focus on leveraging automation to rapidly deploy and manage cloud resources at scale.