Azure Deployment Slots – a brief introduction. Deployment Slots are a capability of Azure Web Apps (previously known as Azure Websites). They are only available when you’re using a Standard or Premium pricing plan. If you go into the “Settings” area of your web app, you can click into “Deployment Slots” and from here create a slot. Deployment slots are actually live web apps with their own hostnames, hosted on the same application server as your main app, which keeps the “production slot”. Below you may find some key points about deployment slots, and in particular that they: are available in Standard and Premium pricing tier, offering 5 and 20 deployment slots. Azure App Service brings together everything you need to create websites, mobile backends and web APIs for any platform or device. Free and Shared (preview) plans provide different options to test your apps within your budget.
Azure Sitecore Deployment: Deploying to a Slot
August 10, 2017 | Charlie Turano
This is part 5 in our series of blog posts on Sitecore deployments on Azure. The other posts in this series can be found here:
1. Setting Up the Solution and VSO Build
1. Setting Up the Solution and VSO Build
2. Preparing the Default Scripts and Packages for Azure Deployment
3. Adding Custom Modules to an Azure Deployment
4. Adding Project's Code and Items to the Azure Deployment
In the previous post, we completed our Sitecore Azure setup, including a custom module and our initial project.
At this point, we want to setup Azure staging slots, so the next release of our project can go there. This allows us to deploy the new code to a private website (the slot), and test it before pushing it live for the public to see. We are going to script this, to make this really easy for the devops team to automate. The following tasks need to be performed:
Create a 'databaseless' cd package.
Configure the deployment parameters for the slot
Setup a powershell script to run the deployment
At this point, we want to setup Azure staging slots, so the next release of our project can go there. This allows us to deploy the new code to a private website (the slot), and test it before pushing it live for the public to see. We are going to script this, to make this really easy for the devops team to automate. The following tasks need to be performed:
Create a 'databaseless' cd package.
Configure the deployment parameters for the slot
Setup a powershell script to run the deployment
Create and Upload the Databaseless Package
The Sitecore 8.2 rev. 170407_cd-nodb.scwdp.zip was obtained by following the directions on Rob Habraken's excellent blog post Blue Green Sitecore Deployments on Azure. Please see the section toward the bottom entitled Databaseless SCWDPs, and use this script to generate a Databaseless SCWDP of the CD package.
- Extract the parameters.xml out of the default CD package.
- Open a PowerShell prompt, and run the script with the following
Upload this package to your blob storage.
Configuring the deployment parameters
Using the file azuredeploy.parameters_slot.json.example as a starting point, create a azuredeploy.parameters_slot.json file, which will make configuring the deployment much easier. Most of the settings should be the same as the settings in the azuredeploy.parameters.json file. The notable differences are the paths to the modules (the '_cdslot' variations) and the additional settings for the web and master database servers. The package referenced in the CD package will reference the databaseless package we just created and uploaded.
The azuredeploy.parameters_slot.json should be updated to point at a new MSDeploy package for the instance of Launch Sitecore you are deploying. This will push a new version of the code.
As with the earlier posts, take the _cdslot configuration files for the bootloader, SitecorePackageDeployer and the InstallMSDeployPackage and upload them into your Blob Storage.
You then need to get the public URLs for these files, and add them into your azuredeploy.parameters_slot.json file, mentioned above.
The azuredeploy.parameters_slot.json should be updated to point at a new MSDeploy package for the instance of Launch Sitecore you are deploying. This will push a new version of the code.
As with the earlier posts, take the _cdslot configuration files for the bootloader, SitecorePackageDeployer and the InstallMSDeployPackage and upload them into your Blob Storage.
You then need to get the public URLs for these files, and add them into your azuredeploy.parameters_slot.json file, mentioned above.
The CD Slot Arm Template
Now upload the main azuredeploy slot template to your blob storage (remember to keep the same relative path to the other arm template files as it is in our Github repo).
The Powershell scripts
The powershell script to install the deployment slot is very similar to the script used to install the original instance, instead it uses the azuredeploy_cdslot template instead. The example script is called ProvisionAndDeploySlot.ps1.example. You should update the parameters to point to your Sitecore installation and execute the powershell script. This will install a slot called 'cd_staging' in your azure web instance, along with the new version of the LaunchSitecore site (remember, you updated the package path to the new MSDeploy package).
Once run, this entire Staging slot is provisioned with a clean version of the code from the new release. It is currently using the same databases as production though (more on that in the next post), but it is kept private, allowing us to test the new code out to see how our site looks, before affecting any of our public users.
Once run, this entire Staging slot is provisioned with a clean version of the code from the new release. It is currently using the same databases as production though (more on that in the next post), but it is kept private, allowing us to test the new code out to see how our site looks, before affecting any of our public users.
Swapping live for Staging
Once the staging instance has tested and we are ready to push live, the instance can be easily swapped out with the one in production. Select the cd server in the Azure dashboard and click on the Swap button:
Viewing the website, we can see that the new release of our code has been deployed to the production website. Because we had it running in the staging slot earlier, it has already been warmed up and there is no downtime to our front-end users.
Catching up? Start at the beginning! Check out Part 1 of our series, or read the complete project on Github.
Every App Service resource in Azure has the ability to have multiple deployment slots configure. These deployments slots are a feature than can greatly help with the implementation of streamlined testing, staging, and deployment process. Along with the ability to configure multiple hosting environments, the use of Deployment Slots enables zero downtime when deploying application changes, or even rolling back a failed deployment.
Creating Deployment Slots
Deployment slots are a feature of Azure App Service Plans. As a result, every App Service resource (Web App, Web API, Mobile App) in Microsoft Azure has the ability to create up to 4 additional deployment slots with the Standard tiers, and up to 20 deployment slots with the Premium tiers.
Each App Service (in Standard tiers) can have up to 4 additional Deployment Slots in addition to the Production slot.
Each Deployment Slot allows for a separate instance of the application to be hosted in isolation from the other deployment slots and production slot of the App Service. The VM behind each Deployment Slot is the same VM Instance that hosts the production deployment slot. This means that the App Service and 4 additional Deployment Slots will all be hosted in and share the same VM Instance and resources.
To create App Service Deployment Slots in the Azure Portal, just navigate to the App Service, select the Deployment slots section and click the Add Slot button to create a new Deployment Slot.
Additionally, in order to use the Deployment Slots feature of Azure App Service, the pricing tier must be either Standard or Premium. The Free, Shared, and Basic pricing tiers do not support deployment slots.
It’s important to keep in mind that all Deployment Slots share the same VM Instance and server resources.
Deployment Slot URL / Endpoint
Azure App Service applications get a unique URL that is made up of the App Service Name as the subdomain of the azurewebsites.net domain. In the above screen shot, the App Service Name is “testapp2063” which means the URL / endpoint for the Production slot of the App Service is located at testapp2063.azurewebsites.net.
When creating Deployment Slots each slot gets it’s own URL / Endpoint. The endpoint for each deployment slot derives from the endpoint for the Production slot by appending the name of the deployment slot with a hyphen.
With an App Service named “testapp2063” the URL / Endpoint for the following deployment slots will have the following values:
- dev => testapp2063-dev.azurewebsites.net
- test => testapp2063-test.azurewebsites.net
- stage => testapp2063-stage.azurewebsites.net
Deployment Slot Swapping
Swapping Deployment Slots is the method of copying the currently deployed application code and settings of one deployment slot and swapping it with another. Swapping allows for the deployment of application code to be done from one environment to another very quickly. It also allows for a couple new deployment techniques that didn’t exist in traditional server hosting.
To swap Deployment Slots from the Azure Portal, just navigate to the list of Deployment Slots for an App Service or navigate to the specific Deployment Slot that needs to be swapped. Then, click the Swap button and specify which Deployment Slot to swap with. See the above screenshots for reference of where the Swap button is located within the Azure Portal.
When an application is deployed using Deployment Slot swapping, there is zero downtime
Azure Deployment Slots Pricing List
When an application is deployed using Deployment Slot swapping, there is zero downtime of the application. The way this is implemented is by just rerouting the Deployment Slot Endpoint between the Deployment Slots being swapped. Both deployment slots remain running and actively responding to client requests throughout the swap.
Staged Deployment
The technique of performing a Staged Deployment allows for application code to be deployed to a non-production deployment slot (such as one named stage) to test or verify functionality is working as expected. Then once everything has been verified, the Stage deployment slot can be swapped with Production making the staged application deployment the new Production instance of the application.
Incremental Deployment
There are times when deploying application changes might require additional changes other than just deploying the latest code. These requirements could be running SQL scripts or some other post deployment step necessary to fully deploy the latest code. Deploying to a Stage deployment slot can allow for these Incremental steps to be performed after the code is deployed in a way that can be tested and verified before deploying to production.
Rollback Deployment
Every once in awhile a deployment fails for some reason. Maybe files end up corrupt, a major bug is found, or some other reason for failure. In these cases, it’s necessary to rollback a deployment. Using Deployment Slots, a deployment can be rolled back easily buy just swapping the Deployment Slots back.
Azure App Service Deployment Slots Pricing
Basically, swap Stage with Production to deploy new changes. When a major bug is found that requires a rollback, then the Production and Stage Deployment Slots can be swapped back. This allows for the old application code to be rolled back into Production in a matter of minutes. This leads to greatly decreased downtime in the event of a deployment failure.
Azure Deployment Slots Pricing Strategy
Chris is the Founder of Build5Nines.com and a Microsoft MVP in Azure & IoT with 20 years of experience designing and building Cloud & Enterprise systems. He is also a Microsoft Certified: Azure Solutions Architect, developer, Microsoft Certified Trainer (MCT), and Cloud Advocate. He has a passion for technology and sharing what he learns with others to help enable them to learn faster and be more productive.