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).
Related
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 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".
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 experiencing a strange issue with Visual Studio Community 2015 web deployments to azure web apps. I have a Production slot and a Staging slot. When I perform a Web Deploy to Staging, it is also overwriting the web.config in the Production slot!
The web.config is transformed correctly per my staging web.config transformations and I can validate this by looking locally at it in obj\Staging\TransformWebConfig\transformed\web.config.
The log in the build output window in VS all looks correct Updating file (xxxx__staging\Web.config).
Yet when I run the application in the PROD slot, it is pointing to the database that was designated in the Staging web.config. And when I view the web.config in PROD via FTP, I see that all the STAGE web.config transformations are there as well. So from what I can tell, the STAGE web deployment is updating BOTH the Prod and Stage files...well at least the web.config file.
The reverse is also true. When doing a web deploy to PROD, it is overwriting the web.config in STAGE as well.
Is there some sync setting that tells Azure to sync these deployment slots or some other logical explanation?
This looks like you have autoswap feature turned on, so VS swaps slots right after deploy. Two deploys to stage - and you have the same env in both slots.
Our project is in sitecore and using Azure - App service for deployment. We have created staging slot and apart from application setting and connection string want to make some configuration file slot specific(stick to slot while swapping).
Is there a way to make whole configuration file to stick to a particular slot?
We also tried to write some sitecore configuration in app setting option in azure and ticked it to make it stick to slot but still it is getting swapped.
Please help me on this.
Is there a way to make whole configuration file to stick to a particular slot?
No, it is not possible (as of date of writing this answer, as azure is evolving all the time).
Here you can see details of slot swap procedure. My rewriting:
Production slot settings applied to staging slot -> site restart
Staging slot warmup
Host names for production & staging slots get swapped.
Staging slot settings applied to (new) staging slot -> (new) staging slot restart
So basically slot setting is really specific feature; other than that slots are just separate sites, with different host names, ftp shares etc.
Any logic like "I want to have file sticked to slot" should be implemented in some custom way.
For example you can consider using config transforms (you can use this question as a start).
In the Azure portal you can add AppSettings and mark them as "Slot Specific". These can be read from the application using normal System.Configuration.ConfigurationManager.AppSettings semantics.
There's no way to ask Azure programmatically which slot the app is running in to my knowledge.
Alternatively, you can add AppSettings into the Azure Portal's Application Settings and have those setting stick to the slot. These settings will override whatever is in the web.config. For example, if you have an Azure Portal AppSetting of key "Greeting" and value of "Welcome", and the web.config has the same AppSetting with value of "Hello" - the result will be "Welcome". If there is an AppSetting in the web.config that is not in the Azure settings, then it will use the web.config value.