Continuous Delivery WebApps with ARM Templates, Part 1

Cross-posting from personal blog https://cloudmechanic.net

The boss words these days is all about DevOps, Everything as Code, Continuous Delivery, but how do you actually do it? And why should you do it?
Hopefully this post will help you getting started, and by the end of the post provide you with a complete working scenario. So lets get started!

First let me describe the scenario. This case will deploy a simple To-do List .NET WebApp using a Azure SQL Database and monitored with Application Insight.
All code needed for this is provided doing the article, so don’t worry you don’t need to know anything about .NET to test it.

To get that working we need to deploy the following Azure resources, a Azure SQL Server with a database, a AppService Plan with AppService including a Deployment Slot and Connection String,
we also want the AppService to automatically scale according to load and to send email alerts for some common errors.
Finally we want to deploy a Application Insight instance to monitor it all. And then we want to duplicate it all to separate Development and Production, but hey.. That shouldn’t take long to duplicate since we are using templates right?

We want to use Visual Studio Online build and release management to control the entire deployment of both the Azure resource and the web application in two fully automated flows from code commit to production.
This will include some simple automated tests and some manual approvals for going between deployment stages.

In this first post I will show you how to create the pipeline for the Azure Resources.

The first thing we need to do is to create a Visual Studio Online Project to store and manage our solution in. Go to the Azure portal (https://portal.azure.com) and provision a resource of the type Team Project, like you create any other resources in Azure.
If you don’t already have a Visual Studio Online account it will ask you to create one, in Version Control select GIT and leave the rest default.
Currently the VSTS providers in Azure is in preview and you might see that it will load forever, try to just go to the URL of your newly created account directly instead and you will see it is working.

Once you have created the VSTS project you will need to create two repositories within the project, one for the ARM template you are using to deploy the Azure resources, and one for the actual web application code.
The reason for splitting the ARM template and the application code in two separate repositories is that in the most cases I see two different persons working on each of the components.
A developer team is coding the application and then a cloud engineer or DevOps engineer is creating the ARM template need to provision the Azure resource right. Also it will make it possible to differentiate permissions and branch policies.

When the repositories are created it is time to add some code into them.
The application we are using in this case is a sample from Microsoft, they are providing a lot of sample applications for all sorts of things so this is a good place to go if you need some inspiration or just some for testing. https://github.com/Azure-Samples/dotnet-sqldb-tutorial.

For the ARM template I have already created one to deploy the Azure resources I described in the start, you can go and grab it here https://github.com/AndreasSobczyk/Continuous-Delivery-WebApps-Demo.

To add the files to the repositories, you can use a Git client like Visual Studio Code to push the files into the it. See Visual Studio Online + VSCode = Easy PowerShell Source Control for how to.

With all the source code we want to deploy for the solution in place we can now start to create the build and release pipeline. The definitions files for the build and release pipeline is placed in the folder ‘BuildAndRelease Files’ in the same project as the ARM templates.
In VSTS go to Build and Release and select Builds, click the import button the top-right and browse to the local copy of the folder, and import DotNetAppSqlDb_Template – CI.json, this will import the build definition for the ARM template.
On the build definition select Process and select  Hosted VS2017 for agent queue, go to Get Sources and ensure the selected repository is the one for the ARM template.
Next select the Validate Template step, select the Azure Subscription to deploy to (you maybe need to authorize VSTS to the subscription), enter a name for the resource group or select a existing (if not existing it will create one), you should use the same resource group for the build as you use for the Dev environemtn, and select a location.
If you want to enable Continuous Integration go to the Triggers tab and enable it. When done with everything save & queue the build definition, this will trigger a build of the ARM template to validate everything is working.

With the ARM template build done we can create the release definition to deploy it, go to Build and Release and select Releases.
If you have no release definitions yet you have to create new empty one to be able to import, just click the + New definition, select empty process, and save it.
You can now go back to Releases and import the definition by clicking the + on the top-left corner and select Import release definition, browse to the BuildAndRelease Files and import the file DotNetAppSqlDb_Template – CD.json.

This should import a release pipeline looking like the picture below. As this is only the shell of the pipeline we need to add in some information, I have added some numbers to easier identify where to click.
First we need to Add the artifact to deploy, click the box to and select the build definition previously created, ensure Default version is set to Latest.

Next click the lightning at 2. and select After release to trigger the deploy to Dev when release is started, you can also add Pre-deployment approvers if you want someone to review the deployment first.
Now click the 1 phase 1 task at 3. to configure the Dev deployment. Select Agent phase and set Agent Queue to Hosted VS2017.
Go to Azure Deployment: DotNetAppSqlDb-tst and select the same Azure Subscription, Resource Group and Location as in the Build definition.
The Dev deployment is now configured and we can go to the Production deployment,  to switch to the production deployment click on Tasks in the top menu and select Production

Also for the Production slot, select Agent phase and set Agent Queue to Hosted VS2017.
Go to Azure Deployment: DotNetAppSqlDb-prd and select the same Azure Subscription and Location, but enter a different Resource Group for the production workloads, I use DotNetAppSqlDb-dev for dev and DotNetAppSqlDb-prd for production.
Everything for the release pipeline is now configured and you can click Save, and then release to trigger a deployment.
If you want to enable Continuous deployment to trigger the release automatically after each build you can click the lighting at the artifact and click Enabled, if you enable CD you can trigger the build instead and that will trigger the release when done.

When the release has finished deploying both environment, go into your Azure subscription and verify you have two have two resource groups looking like this.

For testing if you want to save some money you can delete both resource groups and redeploy everything at anytime by triggering the build and release.

That is it for now! Next time we are going to create the build and release pipeline for the actual application.