Blog

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 

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

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

.\strip-db.ps1 -PackagePath “MY\PATH\TO\THE\CD\PACKAGE.scwdp.zip” -ParamFile “MY\PATH\TO\THE\EXTRACTED\parameters.xml”

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 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.

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.