The course is part of these learning paths
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 email@example.com.
- Design a release strategy
- Set up a release management workflow using Azure DevOps
- Implement an appropriate deployment pattern
- 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
Now that we have our prerequisites done, we can come down to our pipelines and releases and add a new pipeline. There are some templates here to help you get started with the tasks. In our case, we're just gonna use the blank pipeline, and we need to bolt on our two artifacts. One, we have the HTML code, and two, we have the Azure ARM templates. So we're gonna pick an artifact and we'll use the Azure repo first.
If we choose the drop-down project CDLab, we'll see our hello world. I'll select the master branch and latest version of that code. An alias is created underscore in front of the name, and we have our first artifact.
Next, we're gonna add again and we're gonna choose Github. And now we can see the service connections we created earlier are available here. We wanna search for a repository, as if we were in Github. So this is now using the Azure quickstart templates. If I use the ellipses, I can search partial names and find the projects I need. From the drop-down, we'll choose master and latest version.
We see the alias is created with an underscore and we have our first two artifacts. Now we'd like to create a development environment, so we're gonna push these two artifacts through four stages. There's gonna be development and test and pre-prod and production. Right now, we're just gonna focus on doing the development and test stages. So we'll create a new stage, empty, and we'll call it development. From the development stage, we wanna add another stage called test and, by default, it adds it in order. We can look at the pre-deployment conditions here for the test stage and if we look at the visual representation of what's occurring, if we change our option here for select trigger for the stage after release or manual, we can see that line disappears.
In our case, we are deploying after a stage and we're deploying after the development stage. You can the different choices here in the dropdown. We just need to give ourself a name. And we can save this as our first revision. We now have our first pipeline. If we choose Create Release, we'll get a new release option and we can click Create. We'll see there's Release-1 and we can also go view that release here under View Releases. And here's a history of our releases. So we can see the development environments currently in progress and there's a test environment to go.
If we dive into this release, we get a more visual representation of what's happening and we can look into the logs of what the agents are doing and the tasks that they're executing. So currently it's downloading deltas. However, we had to trigger that manually, which is not really what we wanna do. We wanna automate this process. So while this is underway, we're gonna go click edit our pipeline again and we're gonna add some triggers.
What we want to do is when we push code or pull code into our HTML branch, we wanna create the releases for our development environment and production, so we want a pull request we'll push into production and a development request we'll push through the development and test environments. We're also gonna create a schedule for the test so every Monday to Friday at 3 a.m. the test environment will be updated with the latest development code.
If we click on the continuous deployment trigger for html-docs-hello-world, we can enable both the pull request and push, and we'll create a filter for the master branch on the pull request. We're given a warning here which shows us that zero out of two stages are enabled. That's fine. We'll close that. In the pre-deployment conditions for the development environment, we do wanna add an artifact filter. So we don't wanna update the development branch with master code, so we'll pick our html-docs-hello-world and we'll put the filter in there for dev. In the pre-deployment conditions for test, we're gonna add a schedule, and Monday to Friday 3 a.m. Close that and we'll save. So we'll say Added Triggers.
If we bring up our Visual Studio code that we had connected earlier, we're gonna just change this name and we'll just say a tiny hello world application. Save. You'll need to commit that change, and synchronize it to the cloud. So now, as that synchronizes to the cloud and we come back and look at our release history or our releases, we can see a second release was created and it's kicking off now. If we look at that release, we can actually see here this artifact is the thing that triggered the release and we're running again. I'll just pause this while it downloads the artifacts and we'll see what happens with the test environment.
We can see the development environment's succeeded and our test environment is scheduled. We could choose to deploy that manually. For now, we've completed our first successful trigger to push code through our pipeline.
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.