Azure deployment slots allow your web apps to function in different instances called slots. Slots are different environments accessed through a publically available endpoint. One app instance is always assigned to the production slot, where you can toggle between multiple app instances on demand. This could contribute to have your application always available and deploy different versions without a downtime.
In this scenario we will examine an appservice setup called gservice that has a staging slot.
This staging slot will be used to deploy the code first, then do some health checks and finally swap this slot on production. In this article I will explain only the release procedure. If you want to learn how to build an appservice check the article attached below.
In the initial setup the staging environment and also the production one are both on v1. Lets say that code is pushed on the repository and now the version of the code is v2.
The first thing to do in the deployment would be to deploy the code on staging slot. This is an important step.
The code should be always deployed to staging slot.
Then after the code deployment some health tests will follow. If everything goes as expected we will need to swap the slots.
The swap should be performed always from staging to production slot.
After those two steps on your release pipeline you will have your code published on the production app service and the staging slot will retain the previous build for failover and backup reasons.
