Changing Azure WebApp AppSetting in VSTS

During an application development cycle, we almost always begin by testing locally. Several times, it works locally but not after deployment. But we also do not like deploying directly to the production environment. To solve this, it is common practice to have a Staging environment that works in between.

In Microsoft’s Azure App Service, an App can have several slots from the Standard ties and above (as at the time of writing). I commonly use this feature to implement a Staging slot.

The essence of the Staging slot is to check if everything is okay before making the app version currently running in the staging slot visible in production. Due to this requirement, it is sometimes necessary to have two different sets of resources associated with the app.

For example, if your app uses a Storage Account, an SQL database or another resource that may change with the functionality of the application, you’d want to have two for each. One for the production environment and the other for staging.

Accessing resources such as a storage account or an SQL database requires keys or passwords commonly referred to as application secrets. It is never good to commit such in the source code. Using environment variables is a good option. See this article by Scott Hanselman.

In my obsession with automation, I wrote a small script that would set these variables depending on the environment when deploying the application. The script is below.

param($websiteName, $slot, $key, $newValue)
 
$appSettings = (Get-AzureWebsite -Name $websiteName -Slot $slot).AppSettings;
$appSettings[$key] = $newValue
Set-AzureWebsite -AppSettings $appSettings -Name $websiteName -Slot $slot

An example invocation of this command:

-websiteName "<targetWebApp>" -slot "<targetSlot>" -key "<configurationKey>" -newValue "<newConfigurationValue>"

Example scenario

Assume a WebApp with an automated build configured to build and produce outputs every time code is committed to a repository.

A release agent would be configured to begin the application deployment process for every successful build output.

In the release definition, there’d be 2 environments (Staging and Production) as shown in the image below.

As shown, deployment to the Staging environment is automatic and immediate but the production environment requires approval from a specific individual.

In this scenario, the scripts for staging set the connection strings for the staging then start the slot.