As spoken earlier, deployment slot in azure is hassle free deployment solution for web. In this section we will see how to use deployment slot to get the most out of it. Here we will see how we can swap a site from testing environment to production environment. But before that let me tell you what swapping actually is and what its not.
swap (n) – an acIf yout of exchanging one thing for another.
As the definition says swapping means changing one thing with another on a given situation. In our case, swapping indicates changing between slots. If you have already created multiple slots(staging, production) for your web apps and your tester confirms that site running on staging slot behaves exactly the expected way then you can use the magical SWAP button to swap the production site with the staging site. We can visualize the whole swapping process with the following three diagram.
By default, when an end user request for a site their browser usually hits the production site (Figure 1). With the introduction of deployment slot now it is possible to run multiple version of same site side by side. And since all the deployment slot have its own unique URL so tester, qa, client can check the different version of that particular site anytime they want (Figure 2).
If the new version of that site passes all the test then swapping the slot(by clicking SWAP button or PowerShell/xplat cli command) can make the staging site into production site and vice versa (Figure 3).
For any good reason if you suddenly realize that the changes you have made does not match client’s requirement then by performing the same swap immediately you can get the “last known good site” back.
People often get confused with this overall concept. A lot of them think that swapping is probably changing content from one slot to another but it is not actually! It is more about changing the URL itself along with some site configuration. This is why if you are planning to include/exclude particular file(lets say, robots.txt) during swap you are thinking it wrongly. SWAP option will never give you such flexibility, the only thing it allow you to do is change the URL, mind it. One workaround for such requirements is dynamically served/generate the robots.txt file based on a configuration that is sticky to the slot.
Note to self :
Swap is not about copying the content of the website but more about swapping DNS pointers and that is why you can’t include/exclude particular file during swap.
Enough talk, now show me How
Open the web app for which you already have created multiple slot (staging, qa etc). Then select the slot that you want swap (Figure 4).
This will open up a new blade that will show some more details of that particular slot (Figure 5).
Click the SWAP button which will open the SWAP blade from where you can select which of the slot you want to use as production type. Make sure that the swap source and swap target are set properly. Usually, the swap target would be the production slot. Additionally, you can also check Preview Changes to get some additional information (Figure 6).
Once you are done click the OK button which will successfully swap the sites.
P.S. : If you want to swap a staging site with a site which is currently in STOPPED status then you will get a failure report like the following (Figure 7). On such scenario, make your site in running state first then try again to swap with the staging slot.
We have seen how to swap slot manually but what If we want to make this process automated (instantaneously swap the content and configuration) i.e the website automatically swaps a configured slot (in our case staging) with the Production slot once the deployment completes. In other words, where you prefer continuous deployment of your web app with zero cold start and zero downtime, where pre-swap validation is not needed at all on such scenario Auto-Swap comes handy.
Once enabled every time you push your code to that slot, App Service will automatically swap the web app into production after it has already warmed up in the slot.
To enable Auto Swap type following Powershell command:
Set-AzureWebsite -Name mysite –Slot staging -AutoSwapSlotName production
Before you swap a web app from deployment slot into production, make sure the slot configuration is exactly the configuration intended for the target slot u want to have it for production.
Auto-swap can take a while to swap (1-2 minutes). During this period, under the hood it did exactly same task as when is swapped from the portal i.e
- Makes HTTP requests to all machines to make sure the new deployment is started
- Once all requests come clean flip the switch on the traffic
- There might be some period of draining the old slot – it shouldn’t take new requests for more than 30 seconds and draining depends on your side (e.g. how long it takes to execute request)
Auto-swap only works when deploying using WebDeploy or with Continuous Integration (VSO, GitHub, Bitbucket).
git push will not cause an auto swap.!
- Scaling is not available for non-production slots.
- Linked resource management is not supported for non-production slots