Deployment slots are very useful service from Azure cloud services, this isolate enviorment for developers to develope and test the codes in a seamless manner.The feature swap, enable the developers to rapid deployment and easy roll out roll back.
For an example your web users connected and accessing the original production site on the production slot,you can deploy a new version of the Web App into a secondary deployment slot, so you can test it before it goes live.
Before I tell you even more about what make Azure deployment slots awesome, let me state the facts about deployment slots: Each deployment slot is like a full-fledged App Service instance. The original App Service deployment slot is also called the production slot.
Slots are based on the application services(standard ,premium or isolated)and running on the same application services.There won,t be any additional cost.
Deployment slots are live apps with their own host names. App content and configurations elements can be swapped between two deployment slots, including the production slot. Deploying your application to a non-production slot has the following benefits: You can validate app changes in a staging environment before swapping it into the production. One great feature of Azure Web Apps is deployment slots. I recently had an excellent use case for them as a small startup I’m working with is trying out ASP.NET MVC. In the process, we learned how effectively deployment slots allowed their team to work on the project commit code, test it against a test DB as if in production, then quickly. Deployment Slots in Azure Websites is a way to minimize the impact of broken deployments. Deployment Slots provide you wide variety of deployment workflows. When you create an Azure Website, you are directly provisioned the production slot.
Features
Hot deployments to production with out downtime
Easy roll out and roll back
Benifits of Deploying application to a non-production slot
Validate app changes in a staging deployment slot before swapping it with the production slot.
Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production.
If the changes swapped into the production slot aren’t as you expect, you can perform the same swap immediately to get your “last known good site” back.
Setting up
Suppose, you have a production site which is running and don’t want to disturb the site,create a clone site and modify the codes and test it.
In the Azure Portal, navigate to App Service and click the deployment slots menu item
click on the add slot
clone the site
This will create a same your production site,but the site name is different(with your slot name).
divide your traffic
By default, Traffic % is set to 0 for the new slot, and all traffic routed to the production slot.We can change the traffic % divided to both the slots.
swap
When swap the slots,from a staging slot into the production slot after code changes to know,how the web page looks like with out production downtime and revert back to old.
To configure auto swap:
Go to your app’s resource page. Select Deployment slots > <desired source slot> > Configuration > General settings.
For Auto swap enabled, select On. Then select the desired target slot for Auto swap deployment slot, and select Save on the command bar.
Using powershell create web app
New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]
create slot
New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]
Initiate a swap with a preview (multi-phase swap), and apply destination slot configuration to the source slot
$ParametersObject = @{targetSlot = “[slot name – e.g. “production”]”}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01
Cancel a pending swap (swap with review) and restore the source slot configuration
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01
Swap deployment slots
$ParametersObject = @{targetSlot = “[slot name – e.g. “production”]”}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01
Monitor swap events in the activity log
Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor
Delete a slot
Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01
Azure Deployment Slots Cost
See the video
other references
https://teckadmin.wordpress.com/2019/07/06/create-demo-app-web-site-in-azure-using-azure-cli/
https://teckadmin.wordpress.com/2019/07/06/create-your-first-we-application-in-azure/
This post explains some of the not so well-known features and configurations settings of the Azure App Service deployment slots. These can be used to modify the swap logic as well as to improve the application availability during and after the swap. Here is what you can do with them:
Swap based on the status code
During the swap operation the site in the staging slot is warmed up by making an HTTP request to its root directory. More detailed explanation of that process is available at How to warm up Azure Web App during deployment slots swap. By default the swap will proceed as long as the site responds with any status code. However, if you prefer the swap to not proceed if the application fails to warm up then you can configure it by using these app settings:
WEBSITE_SWAP_WARMUP_PING_PATH: The path to make the warm up request to. Set this to a URL path that begins with a slash as the value. For example, “/warmup.php”. The default value is /.WEBSITE_SWAP_WARMUP_PING_STATUSES:Expected HTTP response codes for the warm-up operation. Set this to a comma-separated list of HTTP status codes. For example: “200,202” . If the returned status code is not in the list, the swap operation will not complete. By default, all response codes are valid.
You can mark those two app setting as “Slot Settings” which would make them remain with the slot during the swap. Or you can have them as “non-sticky” settings meaning that they would move with the site as it gets swapped between slots.
Minimize random cold starts
In some cases after the swap the web app in the production slot may restart later without any action taken by the app owner. This usually happens when the underlying storage infrastructure of Azure App Service undergoes some changes. When that happens the application will restart on all VMs at the same time which may result in a cold start and a high latency of the HTTP requests. While you cannot control the underlying storage events you can minimize the effect they have on your app in the production slot. Set this app setting on every slot of the app:
Azure Deployment Slots Cost Per
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG: setting this to “1” will prevent web app’s worker process and app domain from recycling when the App Service’s storage infrastructure gets reconfigured.
The only side effect this setting has is that it may cause problems when used with some Windows Communication Foundation (WCF) application. If you app does not use WCF then there is no downside of using this setting.
Control SLOT-sticky configuration
Originally when deployment slots functionality was released it did not properly handle some of the common site configuration settings during swap. For example if you configured IP restrictions on the production slot but did not configure that on the staging slot and then performed the swap you would have had the production slot without any IP restrictions configuration, while the staging slot had the IP restrictions enabled. That did not make much sense so the product team has fixed that. Now the following settings always remain with the slot:
- IP Restrictions
- Always On
- Protocol settings (Https Only, TLS version, client certificates)
- Diagnostic Log settings
- CORS
If however for any reason you need to revert to the old behavior of swapping these settings then you can add the app setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS to every slot of the app and set its value to “0” or “false”.
swap Diagnostics detector
If a swap operation did not complete successfully for any reason you can use the diagnostics detector to see what has happened during the swap operation and what caused it to fail. To get to it use the “Diagnose and solve problems” link in the portal:
From there click on “Check Swap Operations” which will open a page showing all the swaps performed on the webapp and their results. It will include possible root causes for the failures and recommendations on how to fix them.