I have been using the Azure WebApp Configuration task (Visual Studio Marketplace) by Pascal Naber to maintain Azure app services’ appsettings from Azure DevOps. So far I’ve liked it but it has some drawbacks and one of them is the usage of it. When you first time see it, you really can’t know how does it work. Fortunately, it is not difficult to use if you just first read the documentation. But it has been difficult to make my co-workers use it because there is some learning curve.
In near days I got a new Azure app service and searched if there are some other tasks in Azure DevOps to make the same. Then I found this by Microsoft: Azure App Service Settings task. Even if it is preview version it seemed promising and I thought to try it. This blog post is some kind of review of it and also introduction how you can manage appsettings from Azure DevOps. But remember that at the moment (June 6th, 2020) this task is still preview version. The preview version has been released on May 15th, 2020 so it is only 22 days old when I wrote this blog post.
Managing Azure App Service Appsettings
Managing Azure app service’s appsettings is quite straightforward at first. When we have only one app service and just a few appsettings, it is easiest to maintain them via the Azure portal. But when there are more environments, like development, test, and production, it becomes trickier to maintain all appsettings in all environments through the Azure portal.
One drawback with this manual approach is the lack of rollback. If we change some values, and we figure out that we should restore old values, we have to remember those old values or keep our backup of appsettings.
Another drawback is similar appsetting values between different environments. If we have some common value and we have to change it, we have to do that change separately to each environment manually if we do it via the Azure portal. There is a risk that we forget some environment. Or there can be many appsettings with the same kind of value which is much more tricky to maintain.
There is a way to make this easier with Azure DevOps release pipelines. We can add a task that updates appsettings. With the help of variables, we can handle appsettings in several environments.
Azure App Service Settings task
Then to the main point of this blog post: new Azure App Service Settings task (preview version) by Microsoft. This task works with the json format used in advanced edit in the Azure portal. We put that json to the task and it will update it to the app service.
Below is a screenshot from the task where MySettings value has been changed from “1234” to “1234 5678”. Let’s try to create a release and look what happens.
When we look at appsettings in Azure, MySettings value has been changed to “1234 5678”.
What happens if we remove OtherSetting from the json? We deploy the following json where OtherSetting is removed and to make sure something happens MySettings has a new value:
[
{
"name": "APPINSIGHTS_INSTRUMENTATIONKEY",
"value": "76980dcc-539e-4063-bd08-b17b7db78376",
"slotSetting": false
},
{
"name": "APPLICATIONINSIGHTS_CONNECTION_STRING",
"value": "InstrumentationKey=76980dcc-539e-4063-bd08-b17b7db78376",
"slotSetting": false
},
{
"name": "MySettings",
"value": "Remove OtherSetting",
"slotSetting": false
}
]The result was surprising to me: nothing happened. OtherSetting was still there. Is this a good or bad thing? Well, it depends on the situation. It is safe because nothing can be removed by accident. For example, if someone has added an appsetting manually to Azure. But on the other hand, this makes it impossible to remove not used appsettings from Azure app services with this task. This task is “apply only”. Compared to Pascal Naber’s task, which has the option to overwrite existing configuration, Microsoft’s task lacks this feature. Hopefully, they will implement it before releasing this.
Using Variables to Avoid Duplicates
It is not rare to have two or more appsettings with not the same values but close to the same. In our case, APPINSIGHTS_INSTRUMENTATIONKEY and APPLICATIONINSIGHTS_CONNECTION_STRING both include the same GUID value (76980dcc-…).
[
{
"name": "APPINSIGHTS_INSTRUMENTATIONKEY",
"value": "76980dcc-539e-4063-bd08-b17b7db78376",
"slotSetting": false
},
{
"name": "APPLICATIONINSIGHTS_CONNECTION_STRING",
"value": "InstrumentationKey=76980dcc-539e-4063-bd08-b17b7db78376",
"slotSetting": false
},
{
"name": "MySettings",
"value": "Remove OtherSetting",
"slotSetting": false
}
]We can use variables to help with this duplication. First, we add AppInsightsKey named variable as shown below. Again, to make sure the release pipeline will make the change, we put empty GUID here.
Then we put that variable to replace those GUIDs. Note how we can use variable also as a substring of the appsetting’s value in APPLICATIONINSIGHTS_CONNECTION_STRING.
[
{
"name": "APPINSIGHTS_INSTRUMENTATIONKEY",
"value": "$(AppInsightsKey)",
"slotSetting": false
},
{
"name": "APPLICATIONINSIGHTS_CONNECTION_STRING",
"value": "InstrumentationKey=$(AppInsightsKey)",
"slotSetting": false
},
{
"name": "MySettings",
"value": "Remove OtherSetting",
"slotSetting": false
}
]When we create a release, it will change empty GUID to those two appsettings:
In some cases, this can help to maintain appsettings values where there are the same values used in many appsettings.
Many Environments with Variables
Usually, there is more than one environment. Classically there are three environments: development, test, and production. For example previous Application Insights instrumentation key is a good example: it should be different in each environment. Fortunately, there is a scope for variables where scope practically is same as environment. We can have the same variable with different values for each environment. In this example, there are Dev and Test environments.
Now when we create a release it will deploy appsettings to Dev and Test environments. Below is a screenshot from the Test environment where we can see that it has all-ones-GUID there.
Working with different environments first looks nice but there is one disadvantage to this. The json has to be put to all environments (stages) in the release pipeline. And if we want to add some appsetting we have to do it separately to each environment’s (stage’s) task. It is not that nice.
Pascal Naber’s task does this better in my opinion. It figures out all with variables and thus changes need to be done only to variables.
Rollback
“Oh shit! The app isn’t working anymore because yesterday I changed who appsettings. And I am not sure which I changed and what values they had!”
That is the situation that at least I’m little afraid of. If we maintain appsettings via Azure DevOps’ release pipelines there is a possibility to rollback. We can just redeploy that previous version with valid appsettings. So far I haven’t had to use this for that reason but it makes my life easier when I know there is a “backup” in case of a bad day.
One way I’ve used this is when I’ve removed unused appsettings using Pascal Naber’s task (and at least yet Microsoft’s task lack’s feature to remove appsettings as I wrote earlier). We are often afraid of removing unused appsettings because “if not broken don’t fix it”. That can leave to have many old not anymore used appsettings to make our life more complex. Thanks to the task in Azure release pipeline I’ve been able to safely remove unused appsettings, and knowing that I can easily redeploy old version if something goes wrong.
Conclusion
My first impression with Microsoft’s Azure App Service Settings task was hopeful. The usage of the same json format as used in Azure looked good. Compared to Pascal Naber’s Azure WebApp Configuration task it is easier to understand: it will simply put that json to Azure app service’s appsettings. While using Pascal Naber’s task it has been difficult to explain its usage to others not familiar with it. Using only variables that are outside of the task itself isn’t self-descriptive and you have to know the syntax.
But when I tried first times Microsoft’s task it lacked many of the good features that Pascal Naber’s task has. It was not able to delete appsettings and json had to be copied to each environment (stage) in the release pipeline. Those were a disappointment for me because I’ve used those features to maintain appsettings in Azure app services.
We have to remember Microsoft’s task is still in preview. So it will probably improve from this. I will keep my eye on its updates and try it again later when it gets new versions. Meanwhile, I will continue to use the Azure WebApp Configuration task by Pascal Naber.
Pros and cons of Microsoft’s task:
+ Uses same json format as Azure’s app service
+ Easy to understand
– Can’t remove appsettings
– Need to copy-paste or maintain json to all release pipeline stages
Sources
Azure DevOps tasks used in this blog post:
- Azure App Service Settings task by Microsoft
- Preview version at the moment of writing this blog post in June 6th, 2020.
- Azure WebApp Configuration task (Visual Studio Marketplace) by Pascal Naber
Lassi Autio's Software Development Blog 