Azure Functions Deployment Strategies

As a serverless architecture, Azure Functions gives us a great benefit, ie. we don’t have to worry about server maintenance. However, we still need to manage our codes and setup a proper strategy for deployment. In this post, I am going to describe list of deployment strategies for Azure Functions.

Git Integration

Azure Functions provides a git integration as an out-of-the-box feature. We can simply integrate local git repository, GitHub, BitBucket or Visual Studio Team Service. For more details, find the other post, Code Management in Serverless Computing – AWS Lambda and Azure Functions.

Git integration is the easiest and simplest way for Azure Functions deployment. However, there are two significant downsides of using git integration.

We can’t modify any code directly on the web editor console

Once deployed, if anything goes wrong, we MUST fix in the developer’s local environment and push it to the git repository to be deployed to Azure Functions. This is OK, as long as we all agree to update any function codes on our local environment first.

We need to have a separate git repository from main repository

Many application development environments don’t only have Azure Functions code, but also contains other code bits and pieces in a repository. In this case, if we use one single repository, pushing changes that are not related to Azure Functions is still deployed, which might cause unforseen side effects.

Then, how do we overcome this issue? We still want to use git as a version control system but also want to be free from those two restrictions. There are two other ways for us.

KUDU REST API

Azure Functions is integrated with KUDU as its backend and KUDU provides us with bunch of REST APIs. With this REST API, we can easily upload a zip file that contains our codes for deployment. Let’s have a look.

We’ve got several Azure Functions codes and they are zipped to ase-dev-fn-demo.zip in the picture above. Once this zip file is uploaded through the KUDU REST API, then all codes in the zip file will be deployed. For now, we are using PowerShell. Here’s the script.

Change [USERNAME], [PASSWORD], [FUNCTION_SITE] and $filePath value and run it. It will upload the ase-dev-fn-demo.zip file to KUDU and KUDU will unzip and deploy it automatically. Once the deployment is done, we can see all the functions are properly deployed.

Of course we can use other environment, rather than PowerShell, as long as it supports REST API call with file uploads.

With this approach, we:

• Use our own repository structure,
• Deploy Azure Functions by creating a zip file, and
• Are able to use web editor in case we need.

MSdeploy.exe / WAWSDeploy.exe

Another one is using the classical msdeploy.exe utility. If we prefer, we can alternatively use WAWSDeploy to utilise Azure web app publish settings.

As we can see above, we have WAWSDeploy utility and the ase-dev-fn-demo.PublishSettings file downloaded from Azure web app. Simply run the following command on our Command Prompt Console:

With this, it will upload directly from your local machine (or build server) to Azure web app. Once it is done, we will be able to see the same result like:

This also enables us to:

• Use our own repository structure,
• Deploy Azure Functions by creating a zip file, and
• Use web editor in case we need.

So far, I have briefly described what kind of strategy we can take for Azure Functions deployment. Each approach has its own benefits and drawbacks. Therefore, based on our business requirements, we can wisely choose one of them.