Overview
In my previous post, we learned how to create ARM template and deploy ARM template using Visual Studio. In this blog post, I’ll explain how to use Azure CI/CD pipelines to provide an end-to-end automation experience to users when deploying an ARM Template via Azure DevOps.
Azure pipeline as a core part of Azure DevOps, it allows for the creation of CI ( Continuous Integration) pipeline in a declarative way using YAML documents, it is also called build pipelines. This capability is also extended to CD ( Continuous Delivery ) Pipelines which is also known as Release Pipelines. It is possible to define multi-stage pipelines-as-code for both Continuous Integration and Continuous Delivery with the same YAML definition file.
Since Github can be easily integrated with Azure DevOps, you can not only build your CI/CD pipeline based on your source code on Github, but also even Mapping your GitHub repository permissions with Azure DevOps.
Solution Overview
In order to use Azure DevOps Build, your Azure DevOps project must contain source code for the application. For this lab, we are using the Azure DevOps project with a Git repository, which I already explained that in my previous post.
Prerequisites
Step 1: Get an Azure subscription
You need a Azure account : Create an Azure account by browsing to https://azure.microsoft.com/en-us/free/
Step 2: Get an Azure DevOps account and create organisation and project. You can check Quickstart: Create an organization or project collection to know more details.
Step 3: Get source from Github repository.
Define service connections
Once you’ve all the prerequisites, it’s time to do some DevOps magic! You will typically need to connect to Azure or any other external services to execute tasks in a job.
There is a separate post on How to create Service Connections on Azure DevOps.
Set up the build pipeline
Build is used to pack up or actually build the application and create the artifact out of that.
In Azure DevOps, my folder structure looks like:
Now, Go to Pipeline and build New Pipeline. Click on “Use the Classic Editor”. It will show the options to select your repo. By default, my Az-ResourceGroup Creation repo is already selected from Azure Repos Git. You can change it to any other source control as well, whatever you’re using for your project.
From the new page shown, we’ll select the ’empty process’ link so that there are no tasks pre-configured for us:
Once your empty build pipeline is ready, you can add tasks in the build.
Task in the Build
Now, we need to first add a task so that we can generate the artifacts. So, we need to click add tasks from left pane and then search for tasks:
ARM template validation
Choose Azure Resource Group Deployment. Click Add.
This step can be used to deploy to Azure and you can set it up.
Display Name and Azure subscription
Give the deployment a name and connect it to you azure subscription. It might ask you to authenticate.
Action
Use default action: Create or update resource group.
Resource group and location
For the resource group you can use a drop-down to an existing resource group, or you can type one down. It will be created then. Set up a location to your preference. I’m using all those values as variables and values are assigned under Library section.
Template, Template Parameters, Deployment mode
Next to the Template-area, you can click the three dots to select your template in the repository. Do the same for the parameter file. Set the Deployment mode to Validation only. This way nothing will be deployed, only tests will be run (it will create the resource group if it doesn’t exist though).
You can now save this step and move on to the next step.
Publish artifacts
Now, we need to create the artifacts, so that It can be available in release Pipeline for access to the files.
Add the step Publish Build Artifact to achieve this.
Change path to publish, to only make the deployment files available. Click the three dots and select the folder.
The build pipeline will look like this:
That’s it. You can now use Save & queue to run the build immediately or just save, which will make the build available for new commits. We now have a ready build definition for CI purposes.
Set up the Release pipeline
After the build, it’s time to set up the release to deploy directly to Azure. The general guideline is to create a release definition, link it to build and then create a CD pipeline.
Go to your repository and click succeeded in the top right. When you do, a button will become available saying “set up release”
Click the button and a new window will pop up. You can select a template, similar to the build-steps. Again, choose empty job. Change the Stage Name to “deploy to Azure” and close the stage-Window with the x in the top right corner.
Click on the Name of the release pipeline at the top of the screen to make it more descriptive.
Artifact
Click add an artifact. The screen will default to a Build as a Source type. In the drop-down, select the build we have just set up. Specify for the release to use the latest build. Keep the other settings as they are.
Tasks
Now click “1 job, 0 tasks” at the deploy to azure-stage. Here you can add steps like you did for the Build. Create a new Azure Resource Group Deployment-task
At this step, you can repeat the settings for the subscription and resource group that you used in the Build.
When you set up the Template and parameters though, you need to change these to the files that were created by the build. For this, you can again use the three dots to navigate to them.
The most important difference here is the deployment mode. Here you set it to incremental or complete.
Which you choose depends on your needs. I leave it to incremental as I don’t want to override excising resources.
Trigger the Release
Once you have added the steps, you can trigger the release, which will deploy all the components on the Azure Portal.
Once its complete, we can see the resources deployed into the Azure Portal.
That’s it.
