Azure DevOps - Always Be Shipping!

How to update application settings of an Azure Functions App in Azure DevOps Pipeline

This post was most recently updated on February 25th, 2022.

3 min read.

This article aims to patch one annoying gap in Microsoft’s documentation: how, exactly, do you update Azure Function App’s application settings using an Azure DevOps build/release pipeline? It sounds easy, and something that should happen almost automatically – and for Azure Web Apps (or App Services, as they are often called) it IS practically automatic.

But for Azure Functions, it isn’t. And the docs aren’t perfect. Let me try and fix that.

Problem

Azure Functions won’t take your appsettings.json file, “mapping” your variable groups or creating pipeline variables doesn’t do anything, and Azure DevOps doesn’t even provide a task for “managing application settings” or whatever.

But the solution is fairly simple, nonetheless.

Solution

There’s actually an optional parameter available for the Azure Functions deployment task – let’s see how to configure and use it!

Time needed: 10 minutes

How to update application settings of Azure Functions using AzDO

  1. (Optional) Configure your variable group

    Add your desired app settings as variables. Remember the name of your variable group, you’ll need it later!



    Alternatively, you can just define your variables as pipeline variables. But using the variable groups is often easier for centralized management, and because of the Azure Key Vault integration.

  2. (Optional) “Import” your Azure DevOps variable group to your pipeline

    There’s probably a better word for this – but you can “import” or “reference” your variable groups from a lot of tasks on Azure DevOps using a syntax like shown below:



    This’ll enable your task to use the variables like they were defined as build pipeline variables – which is really neat!

    If you’re not using variable groups (i.e. you skipped the first step too and simply defined pipeline variables), you can skip this one as well.

  3. Add a task that supports appSettings transformation

    Okay – so this is one step that could easily go wrong, as the way application settings are updated for Azure Functions is quite a bit different as opposed to an App Service or IIS website deployment.

    Instead of enabling XML/JSON transformations or some other neat and semi-automatic way of replacing application settings, you’ll need the properties that are to be overwritten to variables one by one – and you need to select the right task for the job!

    Aaaaand the right task is called AzureFunctionApp@1. A little bit underwhelming, I know – but the real beef comes next…

    (Although – if you DO like JSON instead, skip steps 3 & 4 and jump right to step 5 instead…)

  4. Insert the following (which looks very redundant, but works, I assure you)

    One of the inputs this task accepts is called “appSettings.” You can overwrite app settings one by one – like follows:

    task: AzureFunctionApp@1
    inputs:
    azureSubscription: $(serviceconnection)
    appSettings: '-CosmosDbConnectionString $(CosmosDbConnectionString)'


    Yes – in this configuration, we’re overwriting an application setting called “CosmosDbConnectionString” with whatever value comes from a variable in the mapped variable group (imported in step 2), or in the pipeline variable (takes precedence).

    You can obviously add multiple overwrites, and you don’t have to use variables – but most of the time you probably will want to!

  5. (Alternative): You can also use the AzureAppServiceSettings task

    As Matt points out in the comments below, if you DO have your future application settings neatly packed into JSON -form, you could also use AzureAppServiceSettings task instead. Way more convenient – but I passed on this as I was not in possession of such a thing.

    A sample of how to use the task is below:

    task: AzureAppServiceSettings@1
    displayName: 'Set Application Settings'
    inputs:
    azureSubscription: $(ServiceConnection)
    appName: $(AppName)
    resourceGroupName: $(ResourcGroup)
    appSettings: |
    [
    {
    "name": "MySetting",
    "value": "MyValue",
    "slotSetting": false
    }
    ]

That’s it! Now you know another thing that’s not properly documented anywhere online.


Here’s a more complex YAML sample for your copy-pasting use:

trigger:
- main

variables:
- name: serviceconnection
  value: 'my service connection'

stages:
- stage: AzureFunctions
  dependsOn:
  pool:
      vmImage: 'windows-latest'
  jobs:
  - job: Build_AzureFunctions
    # omitted for clarity 

    # deploy to Azure Web App dev/staging
  - job: DeployToDev
    variables:
      - group: Development.AzureFunctions
    dependsOn: Build_AzureFunctions
    condition: succeeded()
    pool:
      vmImage: 'windows-latest'
    steps:

    - download: current
      artifact: drop_af

    # Deployment to Azure Functions
    - task: AzureFunctionApp@1
      inputs:
        azureSubscription: $(serviceconnection)
        appType: functionApp
        appName: 'my-functions'
        package: $(Pipeline.Workspace)/**/$(AzureFunctionsName).zip
        appSettings: '-EventHubConnectionAppSetting $(EventHubConnectionAppSetting) -CosmosDbConnectionString $(CosmosDbConnectionString) -AzureSignalRConnectionString $(AzureSignalRConnectionString)'

Hint – in case you’re wondering how to access these application settings/properties in your Azure Functions code, see this article for details!

References

mm
5 1 vote
Article Rating
Subscribe
Notify of
guest

4 Comments
most voted
newest oldest
Inline Feedbacks
View all comments