Azure Function App is a serverless solution that allows you to execute small, event-driven, pieces of code without worrying about infrastructure. It supports various languages, and one Function App can host multiple Azure Functions. You can write less code and maintain less infrastructure, and instead focus on the code that matters to you, in the language that works best for you.

FlexDeploy’s Azure Plugin provides many options to better manage deployments to the Azure cloud. In this blog, I will cover:

• How to deploy a .NET (or any other) application to Azure Function App
• How to manage dynamic Application Settings & Connection String properties
• The option to remote build code in Azure
• How to optionally retrieve the deployment log against the deployment executed
• The deploy to slots capability

Pre-requisites:

Before starting, you will need the following:

• Your Azure Account should be configured as a Cloud account under the Topology section of FlexDeploy. It should have Client ID, Client Secret, Tenant ID & Subscription ID configured in it. The Client ID must have relevant access in the target Function App to deploy code and make other associated changes such as Application Setting updates, etc.

• This operation is not going to create the Function App infrastructure. Preferably use FlexDeploy’s ARMTemplate plugin operation to create the infrastructure prior to deployment.

Build and Deploy .NET Application to Azure Function App

Build tools or applications can be used in a Build Workflow to create the executable artifacts (e.g. maven for Java, .NET publish for C#, npm install for node js, etc). Use the FlexDeploy Azure plugin operation deployFunctions in the deploy Workflow to deploy any code archive to the Azure Function App. It expects the archive with necessary artifacts to be created as part of the Build Workflow and present in the Artifact repository.

The build artifact archive (*.zip file) should contain the code executables. You can see in the image below, for the .NET application the .dll files are present in the zip file. Similarly, it will be *.jar for the Java archive inside a zip file.  I will cover this in more detail in the the Remote Build in the Azure section of this blog.

     

If the App Setting & Conn String files are passed as files, they will also be part of the artifact. I will cover this in more detail in the App Setting/Connection String section of this blog.

Preferable Git Repo Structure

The git repo should contain the codebase. It can also contain any App Setting & Connection String related attributes in respective files. Any naming convention is allowed.

Managing Application Settings & Connection Strings

Under Project properties, you will need to provide the Application Setting and Connection String file names. While the Application Setting and Connection String properties are non-mandatory and can be directly provided as a plugin Input as well, it is recommended to add them in the Project properties.

Additionally, the files should exist in WORKDIR during execution. The folder hierarchy is not required as the plugin will search the file based on the file name. Note that only one Application Setting and one Connection String file are allowed per project.

Application Setting and Connection String are two separate entities, and the added files will be considered during deployment.

Let’s review the sample AppSetting file first, which has the same structure as settings.json generated by default. There are two dynamic values that need to be propagated to the Function App Application setting.

One of them, DYNAMIC_TESTKEY1, is project specific & environment agnostic.

The other, DYNAMIC_ENV_TESTKEY2, changes per environment.

Both properties need to be created in Workflow Properties with the relevant Property Scope.

In the Project properties, we need to provide the relevant Dynamic Values.

For the Environment property, the same Dynamic Values need to be added against Env-Target Group properties.

The Application Setting and Connection String can also be passed as an input argument of the deploy plugin, as shown below.

Refer to the Product Documentation for the input structure of Application Settings and Connection String when passed as a file or as an input parameter.

In case both the Application Setting file and the application setting input argument is passed, a consolidated list of properties will be considered while updating the Function App. If the same attribute is used both in the file and the input, the value provided as part of the input will take precedence. The same applies to the Connection String.

Please note that it is not mandatory to have dynamic values. One can always pass static ,hard-coded value if needed, although that is not recommended.

Application Setting and Connection String values will be updated in the target Slot Name configured at the environment level.

Deploy The Code Archive to Function App

The plugin will search for a *.zip file under the artifact object and will deploy the same in Azure Function App.

Only archives with zip extensions can be deployed. Thee language of the function inside the archive must be in line with the Azure Function App runtime. The archive will be deployed to the target Slot Name configured under the environment.

Remote Build for Azure functions

There is an option to perform a remote build (e.g. for node js /dotnet codebase) where the vanilla codebase can be uploaded to Azure infrastructure and the code build happens in Azure infrastructure itself.

To perform a remote build, you need to check the Remote Build flag under Project properties.

In such cases, the code archive needs to be created as an artifact object. However in this case the vanilla codebase (without any compilation or executable files) needs to be inside the archive as shown below.

Once the Remote Build flag is set, the plugin internally sets two Application Setting properties inside Function App so that Azure itself does the compilation.

Show deployment log

Once deployment is completed, in case someone wants to verify the execution steps, they need to check the Show Deployment Log checkbox under Project properties.

In this case, the plugin will internally retrieve the deployment ID and will fetch the Deployment log (if available), and return the same as an Output variable.

This is applicable only for Code archive deployment, and is not available for docker image deployment.

Deploy to Slot

The default Azure Function App slot is production. However, you can configure multiple slots and deploy functions on those slots inside the Function App. The slot name is a mandatory field indicating where the code needs to deploy.

In case you wants to do a slot swap, you can provide the target slot to be swapped with as shown below.

This is an environment-specific property and should be updated under the environment-target group properties section accordingly.

Conclusion

With the advantage of FlexDeploy’s tool chain integration and release and pipelines functionality, you can manage your Azure Cloud deployments in an easy and effective way.