Using Azure App Settings To Store Deployment variables

Photo: Andy Crouch

Automated deployments are the expected way to go these days for good reason. The approach of automating everything has long run through the development profession. Books such as the Pragmatic Programmer drum home the issue and providing the reasons why. All hosted platforms provide a mechanism for automation and you should take advantage. No matter what size your project is.

We have used standard Git (Bitbucket) deployments with Azure since our inception. We’ve never had any issues until this week when we had to handle a difference between the Production and Staging environments.

A developer deployed an HTTP Rewrite rule to the Staging environment that should only be deployed to Production. The developer had assumed that as there were some configuration specific web.configs that they were tied to the deployments. This is not the case. When you set up the automatic deployments via Bitbucket or Github you end up having a .deployment file in your repo root directory. This file provides some settings for Azure to honour. The configuration dependent web.configs actually relate to when we had our own in-house developed script to perform releases. Proof if ever there was any that cleaning up your projects as you go is key to minimising confusion (broken windows).

Anyway, I digress. After some research, a recent addition to Azure is the ability to specify the same contents that are included in the default .deployment file as App Settings on your App Services. Now, this is not ideal but it is better than finding a way to script differences within a static file. Full details can be read here.

The premise is very simple. If you have a line in your .deployment file such as

SCM_BUILD_ARGS=some-string-arguments-and-configuration

The left-hand side of the = side becomes the App Setting Key contents while the right-hand side becomes the App Setting Value contents. (The = character is not required). This allows you to tailor your deployments to a specific build configuration.

The only downside to this approach is that you end up having to apply the deployment settings per App Service. However, as you would be scripting the creation and setup of your App Services this won’t be a problem, will it?