Leveraging Deployment Slots
The first thing to know about deployment slots is that they are live apps with hostnames, content, and configuration settings. In a common modern development workflow, you’d deploy code through whatever means to a non-production deployment slot (often called staging, although this could be any name and there could be multiple slots between that and production) to test and validate. From there, you may start increasing the percentage of traffic that gets routed to the staging slot when people access the production URL, or you may just swap the slots. Whatever was in production then goes to staging and whatever was in staging goes to production, with no downtime.
Because it is just a swap, if something unexpected does happen as a result, you can swap the slots back, and everything will return to before the swap occurred. Several actions take place during a swap, including the routing rules changing once all the slots have warmed up. There’s a documentation link in the Further Reading section of this chapter should you wish to explore this further. Essentially, there’s a load balancer involved that routes traffic to one slot or the other; when you swap the slots, the load balancer will route production traffic to the previously non-production app, and vice versa.
You read about application configuration settings earlier in this chapter, but we didn’t address what slotSetting meant. With each deployment slot being its own app, they can have their own application configuration as well. If a setting isn’t configured as a deployment slot setting, that setting will follow the app when it gets swapped. If the setting is configured as a deployment slot setting, the setting will always be applied to whichever app is in that specific slot. This is helpful when there are environment-specific settings. For instance, perhaps you have some connection strings that are only for production, and you want whichever app is in the production deployment slot to always use that connection string, regardless of swapping that might occur.
Different App Service plan tiers have a different number of deployment slots available, so that could be a consideration when deciding on which tier to select or scale to. As with some other settings we’ve discussed, Windows apps have an additional setting that’s not available with Linux/container apps: auto-swap.
Under the Configuration blade of a Windows app service and the General settings tab, you’ll see the option to enable auto-swap when code is pushed to that slot. For example, if you enable this setting (again, only available on Windows App Services) on the staging slot each time you deploy code to that slot, once everything is ready, App Service will automatically swap that slot with the slot you specify in the settings. Don’t be disheartened if you want something like that but you’re using Linux/container apps. There are plenty of ways to programmatically achieve a similar experience, using CI/CD pipelines, for example.
