I found out the hard way that 'IP restrictions' set up for a deployment slot are included in the deployment slot swap, despite the fact that the 'Which settings are swapped?' section doesn't really make note of that.
I expected them to stick with the slot considering it seems to fit along with the accessibility of the running instance settings (such as the custom hostname configuration and such).
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
It appears that hybrid connections are also swapped
@ghills Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.
@ghills Thanks for the feedback. I brought it up with the product team. They agree that it shouldn't be swapped and also mentioned that a fixed is being rolled out in a few weeks.
I'll add hybrid connections to the list in the doc.
@cephalin to add onto this, we had a very similar experience with CORS today at work. We spent a large portion of the day troubleshooting an issue that ultimately came down to our CORS setting being swapped from staging to production, back and forth.
I would think CORS should not be swapped as well (or at least made as a slot setting)
@cephalin should I make another ticket for this? I'm just not sure if CORS is intended to be swapped and should be documented as such, or if it is to be fixed similar to IP restrictions in this ticket.
I checked with the product team. Sounds like CORS is not included in the current fix. I'll update the doc accordingly.
@ghills @jpreese Thank you both for the feedback. The team has prioritized getting it fixed for IP restrictions, VNET, hybrid connections, and CORS. By end of January all of them should be unswapped by default.
@cephalin I think that is the right solution - thanks for keeping us informed.
Sounds great! I agree this was a little confusing at first. I couldn't really think of a reason why you'd want these swapped.
@ghills @cephalin just to pose a mini question, what is the use case of not having a setting set as a slot setting? It seems to me that all use cases would favor slot settings. The only stretches I could think of would be:
I really think the behavior should be "slot setting" or some sort of "inherit from parent". Slot setting is exactly how it is today, but "inherit from parent" would be settings that we want to be the exact same for each deployment slot for that app (maybe a mysql user name, CORS, etc) as a means to reduce typing in the exact setting for every app when you intend for them to all be the same.
An example of number one in your list is: if you're migrating the database backend for your app and want to verify your changes before swapping to production. In this case you'll want the migrated database connection string to be swapped into production along with the new app code.
Yeah that was one of the use cases I could think of, the slot setting depending on the code. Seems like most would be slot settings, but they definitely have a use case.
Any updates on this? We had some production issues since Hybrid Connections were swapped unexpectedly.
Hi everyone, last week we made the following items sticky to the slot:
We are planning to make the following settings sticky to the slot as well:
I updated the lists in the documentation last week.