Sitecore.com Continuous Deployment on Azure (2019 Edition)

It's been a while since my previous post about continuous deployment with Sitecore, lots of things have changed since then, www.sitecore.com is now hosted on Azure PAAS, the team is using Azure DevOps instead of TeamCity and much more. Over the past few years we completely revamped our deployment infrastructure and processes, and in this blog post I'll share how our current setup looks like after all of those iterations. Hint: it is now extremely simply and basically configurable in point-and-click manner.

Preface
One of the major requirements for us was being able to test the features and fixes in isolation, that's where the release flow and pull requests came handy. Here's how we do branching in GIT (read more about this strategy):

This way we always have "ready to release" master branch, as well as can easily merge and deploy hotfixes.

We use the following environments:

1. QA (on-prem)
• This is where "topic" (aka "feature") branches are deployed (usually, as pull requests)
• Automated UI tests run after each deployment
2. Pre-production (Azure)
• This is where "release" branch will be deployed before the release
• Automated UI tests run after each deployment
3. Production (Azure)
• Once we validate the build in pre-production environment, we will deploy the same artifact to production
• Automated UI tests run after each deployment

What I refer to as "build artifact" is:

• WebDeploy package with custom files (built by TDS or custom script)
• Item .update package (GIT DeltaDeploy or Sitecore Courier)

On-prem deployment

In QA environment, we test each pull request separately from others. We basically install clean Sitecore instance (XP0) from scratch and deploy custom code on top. All of that takes less than 30 minutes and includes production content restore.

Specifically, we do the following:

1. Deploy new Sitecore instance: using with Sitecore Deploy module from Azure DevOps marketplace
2. Copy over custom code using standard "Unzip zip files to a direcory" task
3. Install items using Sitecore.Ship (version compatible with Sitecore 9.x)

The Install step basically consists of two task:

"Manage IISWebsite" is a standard Azure DevOps task where we set correct bindings for the website. Since we deploy pull requests (PR), we use wildcard domain, i.e. test instance name will be:

pr#id#.#server#.domain, for example: pr1143.server15.yourcompany.com.

Single Windows 2019 server can easily handle 5-10 instances running simultaneously, and this approach scales to multiple servers.

Azure deployment

Azure is slightly different. Obviously, it does not make sense to deploy scaled Azure instance each time before the release, because it would take hours to set up, even if we take Azure Search, Analytics, etc. out of equation.
However, it is still simple: we use App Service Slots and deploy the updated files into the copes of CD and CM instances. The databases are shared between the main app and the slot, therefore we don't need to copy them

Here are the pipeline stages:

1. Create a zip archive of production instance (CM, CD)
2. Create a slot and deploy the website copy there (CM, CD)
3. Deploy custom files using standard "Azure App Service deploy" task (CM, CD)
• It is important to note, that we deploy our updates to the slot, so even if something goes wrong - this will not affect production website
4. Install items using Sitecore.Ship (version compatible with Sitecore 9.x)
• Since we used shared databases, we make sure that the changes in items are not breaking, i.e. the website should work with "old" files and "new" items
5. Review the website deployed to slot (as well as run different kinds of tests)
6. Publish the items and then "swap" the slots in Azure
• "Slot" content is seamlessly moved to production by Azure, and new www.sitecore.com becomes available (without downtime)

Pre-production environment is mirroring production setup, the only difference is that production environment has slightly better specs and all those bindings and certificates assigned. It is particularly useful when you setup or update automation so that you don't break your production website along the way.

By and large
This setup proved to be robust and manageable. There is definitely no "one size fits all" solution, but I'd like to highlight a few important points that make sense for every project if you want to deploy the changes frequently and safely:

• Test features and fixes in isolation, otherwise you will greatly complicate the maintenance and deploying often will be painful
• Automate as many deployment steps possible and run them hundreds times to polish the process
• Use automated UI tests that run after each deployment on any stage to identify the issues early

Don't hesitate to share your thoughts on deploying Sitecore to Azure, as well as your own stories and hints.