Automating Deployment on Azure Web Apps

Editor’s note: The following post was written by Windows Development MVP Matias Quaranta as part of our Technical Tuesday series.

In today’s agile development teams we require more than the old deployment methods like FTP or WebDeploy where one member had the “Deploy” task on the delivery pipeline. I’ll go as far as to say that an automated integration and deployment strategy is a necessity to any team that wants to focus on what really matters, writing code and building products.

Opening concepts

Before we talk about Azure’s implementation and mechanics, let’s define clearly the concepts of Continuous Integration, Continuous Delivery, and Continuous Deployment. On a common scenario, the development team interacts with a source control repository by committing changes to the repository files, Continuous Integration refers to automating the processes involved in integrating the changes that each developer makes into the repository and verifying that these changes don’t break the project. Once the project is validated, Continuous Delivery involves automating the process by which the project’s code is rapidly and safely deployed to a staging environment where you are confident that, if you choose, that code can be deployed on a production environment. Continuous Deployment refers to automating this last step and ensuring that the code is delivered to production without incurring in downtime (or reducing this downtime to a minimum without breaking a possible SLA).

Integrating repositories

From the beginning, the Azure Web Apps service allows for automatic integration with source control repositories (GitHub, BitBucket, Visual Studio Online among the most used). This integration allows Azure to detect changes that development teams commit by registering WebHooks on said repositories. These WebHooks notify Azure once the selected branch has received new commits/pushes, Azure pulls the latest source code version and proceeds to compile / deploy it.
To create this integration, we just need to go into the Settings panel of our Azure Web App and select “Continuous Deployment”.

 
On the next screen we can select which provider suits us better, validate our credentials and pick the branch of the repository on which we want the deploy process to be based on. 

 
Once configured, Azure will make a first pull of the source code, detect what kind of Web App it is (.Net, Node.js, Python, etc.) and build / validate it. Note that this validating process does not (at this time at least) run any kind of Unit Testing, it will basically try to “build” the project, if the building fails, that version of the source code won’t be deployed. 
 

Once the first deploy is done, we have successfully configured an automated integration from our repository to our Web App, future commits/pushes on the repository will trigger new pulling/building/deployment process. One interesting feature is that Azure allows us to go back to previous successful deployments if we need to. 

 
The responsible for this process is called Kudu, and it’s the environment on which Azure Web Apps “live”. Kudu is an Open Source project whose main objective is the automation of Git/Mercurial deployments on Azure, but also provides extensions that add additional features like logging and analytics or integration with third-party services.

Introducing Deployment Slots

We might be tempted to think this is the correct way of creating a Continuous Deployment pipeline for a production level application, but we would be making a potential mistake, if we go back to our concepts, we’ll see that to achieve Continuous Deployment we first need to achieve Continuous Delivery.
The scenario that we just configured will deploy new code versions directly to our production environment, but like we probably know by experience, a fresh application requires some sort of initialization sequence on its first requests, this is known as a cold start and can probably cause downtime when it occurs.
We need to deliver our code to a staging environment before, that’s where Deployment Slots come in. With Deployment Slots you can create environments that run in the same instances as your Azure Web App (no additional cost) but have different URLs, storage, application and integration settings. You can effectively create different versions of your Web App, each integrated with different repository branches if you needed.
In our scenario, we’ll create first a Deployment Slot called staging: 

 
Then, we’ll set the integration with our repository like we did before. You might wonder, if we leave both production AND staging integrated, changes will be deployed to both, and you’d be right. That’s why we must Disconnect the repository from our production environment: 

 
Once done, all code changes will be detected by our staging environment, deployed there and we can test and view them by accessing their own private URLs (commonly the URL pattern is https://mysite-{slot_name}.azurewebsites.net). If we are happy with the changes, we can Swap the slots, effectively sending the Staging version to Production and achieving Continuous Delivery. 

AN IMPORTANT NOTE ABOUT SWAPPING

Up until this point, we managed to integrate our repositories and configure slots to achieve Continuous Delivery. The next step is to automate the Swapping process. On the Settings blade, you’ll find the Auto Swap feature. 

 
The Auto Swap process will kick in once the pull from the repository is built and ready. It will first make an HTTP Request to the Web App in our staging slot and wait for an HTTP OK (200), if it receives it, it will automatically swap the slot contents with the selected destination (production most likely). This HTTP Request is done to provide a warm up process of the Web App and avoid cold starts once the swapping is made.

Conclusion
Following these steps you will effectively achieve Continuous Deployment and incur no extra charges on your Web App, creating a failsafe deploy pipeline and letting your development team focus on your core activity.

About the author
Matias is a Microsoft MVP, Azure & Web Engineer, open source contributor and firm believer in the freedom of knowledge.