Clarification on meaning of "Sticky to Slot" for deployment slots RRS feed

  • Question

  • This is a followup on this post from Azure SQL DB forum


    The response there accurately recounts an understanding of the situation I'm asking about, that is:

    A slot contains a set of application files.  Two slots can contain slightly different versions of the application files, and can have different connection strings.

    During a deployment slot swap the files aren't copied, it's just the DNS's that are pointed differently.

    So the term "production slot" really means the set of files that the DNS points to, even if the actual physical slot that is pointed to (i.e. set of files) is changed.

    My question is, when a connection string is made "sticky to the production slot", and the "swap" occurs, what exactly happens to the production connection string data?

    1) Is it copied to the "new" production slot, like a real file copy? (seems like that would 'confuse' what was actually in the two different file sets)
    2) Is it "pointed to" from the "new" production slot (does not seem that would be reliable, because the "old" production slot could be edited)
    3) Does Azure manage a pointer to the connection string for the production slot that is separate from the app code files?
    3.1) If so, how does it do that?  Does it keep a separate copy of the connection string data?  If so, how does Azure update that data if the "real" connection string data (which might be encrypted) changes?

    I believe this all works.  However, I would like to know exactly how it works before I build my procedures around it.  Because it seems like the applications service can get disrupted by doing it wrong.

    Any guidance on this would be appreciated.


    Monday, July 16, 2018 5:12 PM

All replies

  • Hi codequestor - It's a bit more than just DNS swap under the hood. Perhaps, following might help?

    App services swap behavior discussion

    Ruslan's Blog

    Tuesday, July 17, 2018 3:56 AM
  • Checking in to see if the above answer provided by Mike Urnun helped to solve your problem. Let us know if there are still any additional issues we can help with. 

    Thursday, July 19, 2018 11:55 AM
  • Thanks for the input.  Those are useful posts in terms of managing deployment slot behavior.  However, they do not speak to the initial question that I had which is:

    What exactly happens to connection string and app.config information when "sticky to slot" is implemented? 

    There was a comment in the first suggested URL about that information being "copied over", however, that's not enough to base my procedures on.

    Above I presented three possible options.  However there might be others.   

    This is just technology.  It happens in some specific way.  Someone at Azure knows what that is.  Hopefully the Azure team has published that information somewhere.  Hopefully we can find a link to that information.  If not, then it probably should be published.


    Thursday, July 19, 2018 4:49 PM
  • By default, App Settings and database connection strings are NOT sticky to the slot and will follow the Web App when the test slot is swapped with the production slot.

    What happens if I have a connection string in my web.config file and as an App Setting, what happens if I have both

    Nothing really, as long as the name is unique.  Watch out that you do not have the same name for any connection string or app setting.  If this happens, then, the values configured in the portal were the values accessed by the code.  Therefore, if you have a connection string called StickySlotConnectionString configured in both the portal and a web.config, then changes you make to the value in the web.config will be ignored.

    For more information, you may refer to this blog: https://blogs.msdn.microsoft.com/benjaminperkins/2017/09/04/database-connection-string-when-swapping-between-app-servers-slots/.


    If this answer was helpful, click “Mark as Answer” or Up-Vote. To provide additional feedback on your forum experience, click here

    • Proposed as answer by Swikruti Bose Thursday, July 26, 2018 10:14 AM
    Thursday, July 26, 2018 10:14 AM
  • Hi, I read the blog post very carefully and indicated in it was the fact that the connection strings can be stored on the App Service independently of the source code.  I did not know that (doh!)  So there's no question of "where the connection strings physically are during a swap".

    With that it becomes clear that if a connection string is made "sticky" it means that the connection string will be associated with the DNS pointer. 

    The code doesn't move, the connection strings don't move.  The DNS pointers to TestSlot and ProdSlot are swapped between the two physical slots, and the pointers to the connection strings TestStr and ProdStr are also swapped so that whatever code the production URL points to, that code is associated with the production connection string, and same for testing URL and testing connection string.  

    ProdURL <=> SourceControlA <=> Prod Conn Str <=> Prod DB

    TestURL <=> SourceControlB <=> Test Conn Str <=> Test DB


    ProdURL <=> SourceControlB <=> Prod Conn Str <=> Prod DB

    TestURL <=> SourceControlA <=> Test Conn Str <=> Test DB

    I had to draw a picture with colored arrows to figure it out.

    Thursday, July 26, 2018 7:47 PM
  • Looks like that cleared up. Do let us know if you need further help in this specific topic.

    Tuesday, July 31, 2018 7:20 AM