다음을 통해 공유

Azure Deployment Slots

  • 아티클

Microsoft Azure provides a cool deployment feature "Azure Deployment Slots". Think of this feature as card layers of a web app, where we swap them until our application moves to the Final Production. Using this "Deployment Slots" feature, we save a lot of time and make and run Unit Tests easier before final product delivery.

To understand it a little bit more clearly, suppose one of your clients asks for a change in one of your product that they are using. The simple way for better delivery is to setup only 2 deployment slots "Staging" and "Production" (although you can create more). We made changes that as the client said and push final application to "Staging" for final testing either using a source control or a "publishSettings" file. If your Unit Tests succeeded, you just swap your "Staging" slot to "Production" and make it accessible to the client.

Consider a situation where you left a bug unfixed in your final deliverable and did not notice while running your unit tests, consequently your client sees the bug and reports you immediately. If you're using Azure Deployment Slots, you can use the previous deliverable by re-swap from Production to again **Staging **without stopping your clients business for bug fix.

You can create many numbers of slots, for this example, we just used 2 slots. Deployment Slots in Azure Preview portal can be easily created by going to Azure Web App => Settings => Deployment Slots => Add Slot, as shown below:


Give it a name and make some configurations as you want:

And that is it, you have created your slot successfully as shown in the example.

Note: You must have running "Standard" or "Premium" App Service plan for using Deployment Slots. Each service has a number of limited slots that you can create.

A common problem that we used to confront while using Deployment slots is that if your application is using an Azure database for back-end data, you have to create another test database for your staging slot and make sure that it gets change while swapping from Staging to Production to Production database.

Some settings do and some settings of you web app configuration do not change with slots swap. List of the settings are that are swapped:

    • General settings - such as framework version, 32/64-bit, Web sockets
    • App settings (can be configured to stick to a slot)
    • Connection strings (can be configured to stick to a slot)
    • Handler mappings
    • Monitoring and diagnostic settings
    • WebJobs content

Settings that are not swapped:

    • Publishing endpoints
    • Custom Domain Names
    • SSL certificates and bindings
    • Scale settings
    • WebJobs schedulers