Slot Swap with Preview enables us to run production specific app setting and database connection string in a slot website. This allows us to completely test the new deployment with actual production setting. Slot Swap with Preview also allows us to execute warm-up code so that website doesn't have any slow perf issues due to cold start.
This blog post explains how to perform common management tasks for Azure Web App deployment slots by using Powershell cmdlets. To learn more about deployment slots refer to the Azure documentation and my previous blog posts: Azure Web App Deployment Slot Swap with Preview and How to warm up Azure Web App during deployment slots swap. I'm trying to create a PowerShell script that will delete the staging slot of five cloud services in Azure in parallel rather than sequentially. I have established that I need to use the 'foreach -parallel' command and that it can only be used in a PowerShell workflow but I cannot get it to. I'm trying to create a PowerShell script that will.
There are three main phases in Slot Swap with Preview :
- Deploy new code to source slot website
- Apply Slot Config : Source slot website recycles and starts with destination slot specific settings (app setting and database connection string).
- At this time we can run our test and/or execute warm-up code using source slot website URL.
- Note: both destination and source slot website URLs will be running using destination slot specific settings
- Complete Slot Swap : if the test is successful, we can complete the swap. Now destination slot website URL will run source slot code with destination slot settings
- Reset Slot Swap : if the test fails, we can reset the swap. This will restart source slot website and run under source slot settings
We can do Slow Swap with Preview using Azure Portal as shown below. Note : select the right slot for source.
Here are PS cmdlets to execute Slot Swap with Preview
$AzureWebsiteName = 'azinsights' $AzureRGName = 'InternalConsumptionResourceGroup' $From = 'test' $To = 'production' #Switch-AzureWebsiteSlot -Name $AzureWebsiteName -Slot1 $From -Slot2 $To -Force -Verbose Switch-AzureRmWebAppSlot -ResourceGroupName $AzureRGName -Name $AzureWebsiteName -SourceSlotName $From -DestinationSlotName $To -SwapWithPreviewAction ApplySlotConfig Switch-AzureRmWebAppSlot -ResourceGroupName $AzureRGName -Name $AzureWebsiteName -SourceSlotName $From -DestinationSlotName $To -SwapWithPreviewAction CompleteSlotSwap Switch-AzureRmWebAppSlot -ResourceGroupName $AzureRGName -Name $AzureWebsiteName -SourceSlotName $From -DestinationSlotName $To -SwapWithPreviewAction ResetSlotSwap |
Before executing Apply Slot Config PS cmdlets, here are process ID and AppDomain ID of source and destination slot websites :
Production Slot | Test Slot |
After executing Apply Slot Config PS Cmdlet, test slot website recycled and now using production database. Destination slot is untouched.
Production Slot | Test Slot |
After executing Complete Slot Swap PS Cmdlet, production slot website has same process id as previous test slot website. And the new test slot website recycled and now using test database.
Production Slot | Test Slot |
More Info
Azure Web App Deployment Slot Swap with Preview
Using PowerShell to manage Azure Web App Deployment Slots
Editor's note: The following post was written by Visual Studio and Development Technologies MVPAfzaal Ahmad Zeeshanas part of our Technical Tuesday series.Daron Yondemof the MVP Award Blog Technical Committee served as the technical reviewer for this piece.
Provided the amount of good resources on the demonstrations of Azure App Services, almost every person that I talk to has heard of Azure App Services at least once. But there are a lot of things that they all are unaware of, misunderstand or at least have it backwards. The deployment slots in Azure App Services is one of such features. It is — in my own opinion — the most beautifully crafted feature in Azure App Service, but hard to get a grasp on.
So, I’ve compiled a few common problems people have faced. In this post, I will try to resolve a few questions.
Understanding Deployment Slots — TL; DR
Azure makes it easy, to create deployment slots for App Services. Unlike with other providers. Azure customers can easily perform the following steps:
- Deploy the web application to an online deployment slot.
- Run the tests on a deployment slot, within the live environment that potential testers are going to use. Testing environment and production environment exist side-by-side and provide the similar environment.
- Perform an internal swapping of the IP addresses of both slots (via load balancing and traffic management for both the nodes — slots)
- Update applications with zero downtime
- Swap back to a previous version of your app instantly, with zero downtime for users.
The overall reason to have deployment slots enabled is that it helps your team to run live testing on the production environment, and in case there are some problems on the production slot, it lets you to roll back the swap without having to take your application down for maintenance.
I will dig a bit deeper in the next sections. Keep reading.
Designing your application for Deployment Slots
If you use Azure App Service, then little do you know, you are already using a Deployment Slot to deploy your application to. Yes: Your production environment acts as a primary deployment slot. To enable more deployment slots, you need to have an app service plan that is either a premium, or standard edition. Both editions allow you to add more slots to the app services, which enables your team to work on a live environment to test the application, while maintaining the user traffic on a default production slot.
Figure 1: The amount of deployment slots you get based on service pricing level.
As seen in the picture above, each of the pricing model has a set of slots which you — in your team — can use for different purposes, staging, testing, and more.
Important: The number of slots listed on the pricing chart include the production slot as well. So, in the above image if the number of provided slots are 5, that means you can create up to 4 additional deployment slots, in this case the initial deployment slot where you have your possibl3 production deployment will be the fifth.
Thus, you need to make sure that your team can know how to divide the testing into 4 categories (slots), or 19, in case of premium, so that you can get the maximum out of Deployment Slots in App Services. Although, typically the deployment slots are created in an order of their deployment, such as
- mywebapp-alpha
- mywebapp-integrationtesting
- mywebapp-staging
This way, you can enable multiple slots where your team can test the application on the live environment.
Using Visual Studio Team Services
If you have been using Visual Studio Team Services (or Visual Studio Online, or even TFS), then you won’t even need to migrate anything. Visual Studio Team Services easily integrates with the existing deployment systems, and allows deployment to Azure App Services, directly toward a testing slot. However, if you aren’t using a different source control product, or CI/CD toolset, the only change that you would have to make in your existing DevOps lifecycle systems would be to, change the target deployment endpoint.
For the sake of demonstration, I created a sample release system, where the current build artifacts are deployed to a deployment slot. Look at the following screenshot:
Figure 2: Release configuration in Visual Studio Team Services system.
This way, you can create a separate release system where the previous build artifacts get published to a different slot for different testing system. In this approach, you can set your DevOps systems to deploy released software to a slot, in short amount of time. Rest is taken care of by the cloud, and it automatically manages how to deliver the content.
Configuring release systems manually
If you use Visual Studio Team Services, then the default release system for Azure support a fully featured release system for App Services. However, if you would like to configure these services yourself, you can always collect the deployment credentials and the path where they content should go: Let us use git instead of TFS and see how we can do that.
First, you can go to the Deployment Credentials page of the slotted app service, set up the credentials for the Git and then you can continue to push the changes you make, to the Git repository.
Figure 3: Deployment Credentials being managed in Azure Portal.
Later, under your development environment just do the following:
You can also configure your git remote repositories, to submit the updates to a remembered path, or you can configure your IDE to do that for you, for example you can configure Visual Studio Code to target Azure App Service Deployment Slots directly whenever you want to push your changes, for this option get started here.
Git, or TFS are not your only options. Remember in the beginning, we mentioned that a production environment happens to be a default slot — that is true, likewise, if you have a look at the deployment options provided under your deployment slots, you will find the full list of the deployment options from various vendors.
Figure 4: Deployment options provided for Deployment Slots in Azure.
Azure Powershell Module Download
There can be several benefits for having deployment options in each deployment slots separately. Having multiple accounts, or folders under OneDrive can help you create different directories for your web application, each directory being an online source for your team to deploy the code towards. However, my humble suggestion would be to properly utilize a source control system instead.
Performing a swap
Once the deployment slots have been configured, and deployment starts to flow in the direction of a slot, only step left is to perform a swap on the slot, so that your users can be redirected to the latest version of your web app. In Azure, there are a few important features that you should know,
- Azure performs a swap by internally transferring the traffic from one slot to another.
- No requests are dropped in this process; users either get the old version or the latest version. But don’t get a service unavailable error.
- Azure itself starts the “warming” process, to start up all the services before a user access it.
- There is no overhead of swapping process: A zero downtime for your web application, in this swapping process.
To perform a swap, you can head over to the Azure portal and load the app service. Azure provides an option for Swap on the default page for the app service, you can select that option and then fill in the values.
Figure 5: Swapping process.
In this process, one thing needs to be taken care of, the Source should be set to the slot from where your latest updates will come, and Destination — in most cases — should be set to Production.
If you hover over the help option beside Swap type, you will read the following,
The swap with preview action applies slot specific configuration elements from the destination slot to the source slot and pauses until a selection is made to complete or cancel the swap action.The swap action directs destination slot’s traffic to the source slot after source slot has been warmed up.
Which means, that internally Azure will redirect the traffic for Destination slot, to the Source slot and so on. Nothing will be modified, only the way traffic reaches the destination. And that is how Azure achieves zero downtime during the process of swapping deployment slots.
One final thing left for Deployment Slots is the error handling, what should be done in case the latest release has some bugs, that went unnoticed. In such cases, you just simply repeat the process above but set the Destination to slot1 and you’re good to go, you will simply undo the swap process and your users would start accessing the older version of your service.
However, I would like to mention that the case of running tests on your production environment is not ideal, the case would only happen if your testing systems were faulty, or your testing was incomplete, which led to a bug on live production slot. The production slot should be used for release version of your software, and you must run all sort of testing in your slots — dev, alpha, integration, staging, etc. before you swap to production. Each slot can serve to test application under each condition to ensure that it is working the way it is expected to.
Create Cloud Service Azure
You can also use Azure PowerShell to automatically perform a swap, whenever the tests pass. For example, the following command from Azure cmdlets can do that:
This is just one of the features of Azure PowerShell that we can use, there is a bunch of services covered in Azure PowerShell cmdlets, that you can use. Even to revert the current release from a deployment slot to another.
Powershell Get Cloud Service
Are you using Free or Shared pricing models?
Like I mentioned above, extra slots are available for Standard or Premium pricing plans, in the free or shared plans there is a single slot if is used as the production slot and you cannot add more slots to test the live environment, and the behavior of your application.
To get services of extra deployment slots, you can change the pricing model to fit your needs.
For more information:
Afzaal Ahmad Zeeshan is a Microsoft MVP for Visual Studio and Development Technologies from Rabwah, Pakistan. His primary interest is .NET Core development, Microsoft Azure and ASP.NET Core development and training. He writes articles and blogs for beginners, and loves meeting students and startups over tea. Follow him on Twitter @afzaalvirgoboy.