Pushing configurations, feature flags and key vault secret references from git repository to Azure app configuration store via Azure DevOps pipelines.

Azure app configuration store is an azure service which helps you to centrally manage your application settings and feature flags. All the modern cloud applications generally use application settings to work in different environments, and when your application is distributed across multiple components then it becomes a challenge to manage those configurations manually.

Recently while working on a customer project we created Azure DevOps pipelines to manage the azure app configurations and feature flags. By having pipelines to manage the configurations and feature flags helped customer to control the config changes via pull requests(PR’s). So every time you want to change or add a new config value to any of your environments(Development, Staging, Production) you will go to the git repository make the change to corresponding JSON file and raise a PR, once your PR gets reviewed and merged then pipeline will deploy those new changes to your Azure app config store. Here is an example use case based on what we did in our project.

Lets assume that we have an application comprised of two services, say ServiceA and ServiceB where each service has its own set of configurations.

ServiceA

ServiceB

Note: MongoSettings.ConnectionString and SQLSettings.ConnectionString will be actually a secret references inside azure app configuration store, where the actual values will be stored in Azure KeyVault and the secret keys will be referenced in app configuration store.

Now if we are supposed to manage these configurations for two different environments (Development and Staging) in azure app configuration store. We will create a git repo with following files for each service. You can download the complete sample code from my git repo.

ServiceA
├── config
|   ├──Development-app-config.json      
|   ├──Staging-app-config.json            
├── featureflags
|   ├──Development-featureflags.json    
|   ├──Staging-featureflags.json     
├── secretrefs
|   ├──Development-secretref.json    
|   ├──Staging-secretref.json          
└── pipeline.yaml            
ServiceB
├── config
|   ├──Development-app-config.json
|   ├──Staging-app-config.json
├── featureflags
|   ├──Development-featureflags.json
|   ├──Staging-featureflags.json
├── secretrefs
|   ├──Development-secretref.json
|   ├──Staging-secretref.json
└── pipeline.yaml

• config directory contains json files with non secret configurations for Development and Staging environments.
• featureflags directory contains json files for feature flags for Development and Staging environments.
• secretrefs directory contains json files for keyvault secret references for Development and Staging environments.
• pipeline.yaml has the actual yaml configurations for azure devops pipeline which will read those json files and push the configurations to azure app configuration store.

Note the environment name is prefixed to file name, this is important as when you run the pipeline you need to mention which environment you are running for, so that only that environment settings get updated.

From our examples above if we look at the secretref json files, here is how it looks:

Development-secretref.json
{
"MongoDbSettings": {
   "ConnectionString": "{\"uri\":\"https://<yourkeyvaultname>.vault.azure.net/secrets/<your-keyvault-key>\"}"
}
}

You need to replace <yourkeyvaultname> with your KeyVault name and replace <your-keyvault-key> with the secret key which stores mongo db connection string. So here we are actually storing the reference of keyvault secret as a value to our configuration key.

The config files store the actual config values. However these values can be different for different environments. E.g LogLevel: Debug for Development and LogLevel:Info for Staging.

Running the pipeline.

pipeline.yaml uses the AzureAppConfigurationPush task for pushing configurations from Json files to azure app configuration.

This pipeline uses three push tasks to push three types(configurations, featureflags and secret references) of settings. Here is how the three tasks are configured:

Notice the differences between ContentType for the three tasks.

Feature flags as such are not yet supported by the AzureConfigurationPush task, but if you create the json files based on this schema definition and provide the configuration shown above, you should be able to manage feature flags as well.

Pipeline expects two parameters, the name of the Environment and name of the azure app configuration, after the successful run for both the environments for both the pipelines, here is what you see in Azure app configuration:

Configuration Explorer

Feature Manager

Notice the content type for secret references and feature flags. Also secret references have a special icon to differentiate them visually. We have used prefixes as we were sharing a common Azure App Configuration for multiple services in dev environment.