Deployment slots have been an invaluable feature for Azure Web Apps for a long time. To find out how to create slots for Azure Web Apps, you can visit the official documentation [here](https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing" target="_blank). So what makes deployment slots so useful? I summarize some of the benefits below but this is by no means the exhaustive list:
- [Testing in Production - A/B Testing](GHOST_URL/azure-websites-testing-in-production/" target="_blank)
- Hot deployments that allow deployment to production with no downtime
- UAT testing targeting a near live environment
- Easy roll out and roll back
- Full or incremental swapping
- DevOps integration with slots (VSTS deployment directly to slot)
- many more
There are also some important caveats that you need to be aware of when using slots:
- Shared resources with the live deployment
- Setting persistence
- Load/Performance testing on slots can affect the live site
- Slots are only available on the Standard and Premium tier
- some more
As long as you're aware of the caveats and treat deployment slots, you can significantly improve the way you perform your testing and deployment to Azure. And now Azure Functions can benefit from this awesome feature, which is currently in Preview like [Proxies](https://azure.microsoft.com/en-gb/updates/announcing-azure-functions-proxies-in-public-preview/" target="_blank)
Enable Function Deployment Slots
As soon as you log in to your Azure subscription and navigate to your Functions blade you'll be met with a new item in the navigation pane:
To start using slots you need to enable the feature first (one-time setting). When you press the + you'll be presented with the following message:
Click on the link to enable the feature in the app settings section:
Notice the message above the (On/Off) buttons. This is one-time opt-in on the Function app that cannot be disabled. Feel free to ignore this as slots can be safely ignored if you don't want to use them.
Creating and using slots
I'll use the portal to showcase how to create and use deployment slots.
I haven't seen any updates to the CLI and PoSH cmd-lets with regards to Azure Function slots . I'll update the blog post once I know for sure.
Let's go ahead and create our first slot. Click on the + button next to the Slots item. Enter a name for your slot (make it meaningful as the slot name will be appended to the Function URL. Press Create to go ahead an create that slot. The slot creation is instantaneous.
With the slot in place, we can deploy our code. It's important to notice that the slot operates on the whole Function app and not individual functions. This means that if you plan on using this feature for testing, you'll need to replicate the whole "live" Function code. For my example, I went against my own advice as I'm only showcasing the feature and I don't care about my "live" code.
You'll notice that my new slots comes with it's own unique URL. This is fantastic because I can access this slot in isolation and test it independently from other slots or the code deploying in my "Production" slot which is the default/live slot. The slot URLs have the following format:
https://yourwebsitename-<slotname>.azurewebsites.net
Swapping slots
Assuming that all our tests pass and everyone has signed off the new code, we can now swap the Production and Beta slots. To do this, you need to use the Swap button which is a new addition to the UI.
This will kick off the wizard that will guide you through the swap steps
You need to choose the source and destination slots and the type of swap (simple or with preview). If you want to find the different between simple and swap with preview, check the complete documentation [here](https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing#swap-with-preview-multi-phase-swap" target="_blank). Howwever, if you want the gist of it, see below:
- Keeps the destination slot unchanged so existing workload on that slot (e.g. production) is not impacted.
- Applies the configuration elements of the destination slot to the source slot, including the slot-specific connection strings and app settings.
- Restarts the worker processes on the source slot using these aforementioned configuration elements.
- When you complete the swap: Moves the pre-warmed-up source slot into the destination slot. The destination slot is moved into the source slot as in a manual swap.
- When you cancel the swap: Reapplies the configuration elements of the source slot to the source slot.
Once the swap is complete, you end up with something that looks like this:
With a couple of steps we were able to deploy our code safely to production. I believe that deployment slots are a great addition to Functions and massive Kudos to the team for integrating this feature to the service.
I would urge you to give them a go and see how you can benefit your own work flow and deployment process. As always, feel free to let me know in the comments if you have any questions or issues with this feature.