A production deployment slot is automatically created when you create a new web app. This slot contains the content and configuration for your live web app. You can create up to four additional slots that hold their own independent content and configuration settings. You can access the web apps running in these slots directly, meaning that you can test your web app before promoting it into production. You can swap any of the additional slots with the production slot. Doing so swaps the content and some of the configuration settings with no downtime.

Let's go ahead and create a deployment slot. Firstly, we'll select our web app, followed by deployment slots. To locate the deployment slots, we need to look at the menu on the right, the settings menu, and we're gonna scroll down until we find the deployment slots. And you can find it under publishing and select deployment slots. And a panel should appear and it will say that we have no deployment slots yet. We have in fact got one deployment slot, which is the production deployment slot, but that's not visible. All we need to do is click add slot at the top. We provide a name for that slot so let's call this slot dev and we don't need to worry about the configuration source for now so let's just click okay. And as you can see that's alright. It says that the deployment slot has been successfully created.

Deployment slots support the following types of deployments. Firstly, the staged deployment. In this deployment approach, you test whether the web app is working as expected in the staging slot. Once you're happy that things are working, you simply swap the staging slot with the production slot, bringing over the content and the relevant configuration settings. Similarly, with incremental deployment, if you have certain steps in your deployment plan that you need to perform post-deployment, you can deploy to a pre-production slot. Perform those steps and then swap the pre-production slot with the production slot to make the web app live. Lastly, deployment slots are useful for rolling back a deployment, which we'll cover shortly.

An important thing to note is that when swapping slots, the content is swapped, but the same is not true of the configuration. Configuration items that do come across with the swap include general settings, such as the .NET framework version, web sockets and always on. Connection strings, handler mappings, app diagnostic settings as well as monitoring settings.

Configuration items that do not move across when swapping slots include publishing endpoints, custom domain names, SSL certificates and bindings and scale settings. In practice, this means the application settings such as connection strings should be prepared with production values prior to the swap, assuming you are swapping with the production slot. However, things like your custom domain name, SSL certificates, app scale settings and such, which would normally be specific to the production slot only will not be replaced by swap.

Publishing endpoints specifically ensure that if you are deploying from source control, your production slot will not suddenly get unexpectedly updated because the staging slot you swapped with was configured for deployment from source control. Not swapping scale settings ensures that your production slot, which is handling your live traffic and requires specific scale settings will not suddenly be using the same settings as the low traffic testing environment you just swapped with.

Slots are also very useful for rollback scenarios. In case of a bad deployment, you can simply swap the production slot with the slot that holds what was previously in production. This provides a rapid rollback strategy with no downtime.

Let's have a look at swapping slots. We'll go ahead and swap our dev and staging slots. Here's two that I've already prepared. Firstly, let's ensure that the settings for the slots are different somehow so we can see the configuration swap in action. So if we click on dev and if we wait a while, the settings will appear on the right automatically and we can click on the application settings, which are gonna be under general partway down the settings menu. So now the menu is finished loading, we can click on application settings and we can look at the values that are stored here, in particular we're gonna take a look at always on. The always on value basically means if we're running this app and the app idles, do we make it sleep. If it's off, then it will sleep. If it's on, then it won't be allowed to sleep. If we come down to the app settings themselves, this is like the app settings within a web config, we can see that we've got a value here called ABI endpoint, which has a test.endpoint as the value and it's not been ticked so this means it will be swapped when we do a swap. The environment value has a value that is set to dev and it's been ticked, which means that this will remain the same value so that's the dev settings.

Let's have a look at the staging settings and again if we select application settings and wait for that panel to load, we see that always on is set to on and we have a different value for the endpoint. This one's now staging.endpoint and it's unticked so this one will be swapped. Environment remains the same because it has a tick in the slot setting. We'll now select the swap option. Select our source and destination and we'll get the option to preview the changes. So we wanna swap our source, which is gonna be dev and we'll swap that one with staging. And let's have a look at the preview. And it shows us what the settings are gonna become. So if you take a good look here we can see that the all value is true. That one now is false and that means that the staging endpoint has been changed with the test endpoint. So let's click okay and then click okay again. Now we get a message at the top right hand telling us that the swap is commencing and then a few moments later we'll see another message telling us that it has been confirmed. And if we scroll over to the main screen, we can see an orange message that a swap is in progress. And we can see now that the message has appeared telling us that a swap has completed.

Let's have a look at the test settings again and see the new values that should have been swapped over. And the endpoint for the dev slot is now set to staging.endpoint, but the environment variable has stayed the same. And this completes the demonstration of a swap.

Dotnet Monolithic to Microservices Migration Course Review