I would like to start using the deployment slots in my Azure App Services for a staging to production task. The problem that I am running into is I can't seem to find a way to do transformations on the web.config outside of the appsetting and connectionstrings. I seem to be missing something, but I need to be able to adjust other configurations, from logging levels, to other integrated config sections.
We currently have been using direct deployments from our build server with msdeploy and Parameters.xml file to do much of this work, however that won't work with deployment slots.
When you create the additional deployment slot, you can clone all settings from the existing instance, or dont copy anything. As per documentation:
"You can clone configuration from any existing slot. Settings that can
be cloned include app settings, connection strings, language framework
versions, web sockets, HTTP version, and platform bitness."
In the new deployment slot, under Settings > Configuration, you can specify any settings here to be specific to the new deployment slot by selecting "Deployment slot setting".
Related
We have 4 Azure environments for the stages of our development process; Dev, QA, UAT, Production. As you would expect, settings and options need to differ between environments, e.g., "apiurl": "http://dev-api.ourdomain.com" in dev needs to become "apiurl": "https://uat-api.ourdomain.com" for UAT.
At the moment we manually set these in the App Service Configuration page in the Azure Portal. There are problems with this method we are trying to overcome:
It cannot be timed to happen with releases, it has to be manually done
It's prone to human error
Previous values are lost
We cannot easily compare values between environments
We cannot easily see which settings are no longer used
We would like to setup an appsettings.json with environment transforms for the differences. This addresses the last 3 issues as it will be stored in our code source control (if not secret), but this is useless if we cannot deploy that same file to set the Azure configuration. Pipeline steps might solve issues 1 and 2, but reintroduces issues 3 and 5.
Surely there is a simple way to do this that I am missing?
I'd recommend creating the appsettings.json file in your source code, and use a pipeline to deploy the app service with it included; those settings will take effect. The pipeline can either adjust the file contents immediately before deployment, or upload the file as-is but also deploy app settings to override the file's contents.
This fits your requirements because:
using a pipeline for automation gives you timing control (req 1) and reduces the risk of human error (req 2)
keeping some of the settings in source control gives you a (partial) history of previous values (req 3)
some of the settings may be the same across all environments; those can be left untouched in the appsettings.json, but those which differ can be overridden by the pipeline and adjusted correctly
you could override settings by using a script task such as Powershell or a FileTransform task to actually change the appsettings.json
or, you could override settings by automated configuration of the azure app service configuration, using the Azure CLI or an ARM Template for example.
For comparison of settings across the different environments (req 5), I'd recommend:
organising your pipeline variables into different groups by environment, so the pipeline code makes it clear what the differences will be when deployed
using azure cli or powershell commands to interrogate the actual deployed app services.
I have created multiple slots(test, stage and prod) in my azure app service. Similarly I have created respective web.config files for each environment. I am deploying my application through octopus deployment tool in test environment slot, so initially it's picking web.test.config file and it's working fine.
But, I want to swap complete transformation section of web.config file when I swap it to stage or Prod slot while doing swapping through azure portal. Is there any way to do ?
using application setting and connection string of configuration setting, I am able to segregate the setting of each slot. But I am not sure how can I do it for other section like system.identityModel,system.web system.identityModel.services, etc. Therefore I want to replace complete transformation section according to environment while doing swapping.
When I talked with the app service team, they said slots are not meant for this purpose. The main purpose of slots is to allow deployment of new versions with little or no downtime. Or to test new features with a small percentage of the traffic. Not really for different environments, you should use have separate app services for that, to which you deploy separately.
I do realize I can use Azure AppSettings to override settings in Web.Config files.
https://learn.microsoft.com/en-us/azure/app-service/web-sites-staged-publishing says:
App settings (can be configured to stick to a slot)
Connection strings (can be configured to stick to a slot)
So far so good.
But how do I version these settings?
I don't want to add them manually through the Azure Portal.
Also I don't exactly understand why I can add custom application settings in the Azure App Service release pipeline task. These settings are then copied to the configured slot. Consider following scenario...
There is a new appsetting (which would usually live in Web.Config).
Okay Web.Config is not a good idea because it is specific per deployment slot. So you add it to the release task configuration - for your "staging" slot.
Next you swap staging and production - and of course the new production system has no clue about the new setting (not even the staging configuration which would anyway be equally bad).
I have an existing App Service created in Azure, which has a connection string linking to the database, 'Easy Tables' configured, and a whole bunch of custom API methods and table definitions done via the 'App Service Editor'.
I'm at a stage in development where I need to use deployment slots, in order to have separate environments for development, test, and eventually live.
On creating a deployment slot, I have the option of 'Configuration Source' - where I can clone an existing application.
I select my existing app when I choose this option, however my Easy Tables or API configurations are not carried over with it, and it appears I need to set them up again?
Considering that I already do have everything set up in the App Service, how can I transfer the Easy Tables and API methods over to the new deployment slot without recreating each file one by one.
The end goal that I am trying to achieve is an exact duplication of my current web app - pointing to a separate database, having it's own collection of API calls and easy tables - all using the existing app as a starting point, with a URL different to the existing app.
however my Easy Tables or API configurations are not carried over with it, and it appears I need to set them up again?
Answer in short yes. According the Set up staging environments in Azure App Service, we could know the if we choose WebApp as Configuration Source, it copies the configuration info such connectionstring setting, appsetting etc. not the content of the WebApp.
There is no content after deployment slot creation. You can deploy to the slot from a different repository branch, or an altogether different repository. You can also change the slot's configuration. Use the publish profile or deployment credentials associated with the deployment slot for content updates. For example, you can publish to this slot with git.
I am trying to setup essentially a Development, Staging and Production cloud service. So far I have setup 2 cloud services:
MyApp - which is what I am hoping to have be the staging and production since they have the same connection string and should be identical and the ability to quickly swap VIP is a nice feature.
MyAppDev - I want this to point to our development database.
I also want to do the continuous build integration from tfspreview to azure. This is working great except for making the connection string unique.
So far I have setup the cloud services and have it doing continuous builds. I have also set my connection string in web.config and web.production.config. In addition I have setup publishing profiles (.azurePubxml) files and set them to be the Alternative Publish Profile in the build definition process section. These publish profiles specify which config to use (or at least that is what I thought). It seems to pick up the settings for the publish profile because I have RDP enabled and such with different passwords.
So how can I make the build controller use the "Production" & "Debug" build configurations to pickup the web.config transformations?
Hope that makes sense.
EDIT:
I only have Solution to build as seen below:
When defining your build definition, in the "Process" section under item 1. "Items to Build" you are given the opportunity of defining which configuration to Build. In here, type the name of the configuration that matches your .config definition to build that version.
EDIT: This is a little late, but this is how I got the alternate configuration to build along with the correct connection strings. I set the MSBuild Argument for configuration manually and my build correctly changed the connection strings on deployment to Azure.
Just set your downloaded Azure publishing profile in section 6. "Web Deploy Publishing Profile". It's not necessary to use different web.config files Connection String will be rewritten on publish build runtime.