Deploy From Your Code Management into Azure Web Apps

In this post, I will explain why using FTP isn’t the best way to get your code into an Azure web app and how you can integrate your code management solution into Azure web apps for direct delivery without using FTP. In this example, I will create a deployment integration from GitHub into an Azure web app.
 

 

FTP

In another post, Uploading to Azure Web Apps using FTP, I explained how you could use FTP to publish your code and web content to an Azure web app or deployment slot. That’s a method that has been used for years but it’s very manual. These days, there are better ways to do things.
Code can be shared and stored in lots of ways, including very basic solutions, such as OneDrive or DropBox. More organized teams might use solutions, such as a Git server, GitHub, BitBucket, or Visual Studio Team Services (VSTS). This is not only to share code but also to manage it. So, if we have better ways to store code, manage versions, push/pulls/merges, and to collaborate, then wouldn’t it make sense to integrate these code management solutions into Azure. This would help to deliver our latest and greatest version directly to the web app or deployment slot without using FTP? I think so!

Web App Deployment Options

If you open a web app or deployment slot, you will find under Deployment something called Deployment Options. This allows you to connect your web app or deployment slot (I’ll just talk about web apps from now on) directly to your code management solution and synchronize your code from there.
Azure web apps support a number of external services:

• Visual Studio Team Services
• Git
• GitHub
• BitBucket
• OneDrive
• DropBox

The latter two services aren’t real code management solutions but they could be used by smaller operators as a means of collaboration. We can connect our web app with authentication to one of these services and synchronize the code content from it. As code is updated, a sync command can be run to update the web app repository. The result is that all that FTP mess is replaced by clicking a button.
 

 
When you enable one of the above solutions, a link is created with the storage of the web app. You can:

1. Store/update your code in the code management solution.
2. Synchronize your code into the Azure web app by clicking a Sync button.
3. Execute a stress test against your updated web app.

This approach brings about a structure and ensures that only production/tested code is pushed into production or a pre-production deployment slot in the web app.

Using Web App Deployment Options

There’s no better way to understand something than to see it or do it for yourself. In this example, I have created a project in GitHub with a very simple website.

 
I have deployed a new web app in Azure called petri, which has the default Azure website. My desire is to deploy code from the GitHub repository into this web app on a regular basis and FTP will not suit my operational needs.
 
I browsed to the settings of the web app in the Azure Portal and opened Deployment Options under Deployment. I then clicked Choose Source to see the list of possible deployment integrations.
 
I clicked GiHub and the blade updated to configure an authorized connection to my desired project/repository:

1. Enter your GitHub account username and password.
2. Select a project/repository.
3. Choose the branch.
4. Optionally configure a stress test for your website that will execute after each deployment or synchronization. A VSTS account is required if you wish to store the metrics.

 
The optional configuration to run a performance test is probably best only done with a pre-production deployment slot. You really don’t want to hammer your site while end users or customers are accessing the application!
 
It takes a few moments for the deployment integration to be configured. Once it is, you can go back into Deployment Options and view a log of what happened in the current/last synchronization.
 
Assuming that the default document (Application Settings) is configured correctly for the site, then if I refresh the browser, I should find my custom site will load.
 

 
As you can see, configuring this web app to synchronize from a free GitHub account was extremely easy. If you still don’t want to use a true code management solution, you can just as easily store your code on OneDrive or DropBox and synchronize from there. This will at least give you some structure and level of code control that you won’t have from an FTP upload.