Packaging a Sitecore Deployment — Azure Web Apps Edition

Photo by Conor Brown on Unsplash

Wow, Another Blog Post on Sitecore Deployments ??

I am currently working on a Sitecore upgrade to 10.3.1. The infrastructure in production is going to remain as Azure Web Apps.

Whilst there are many blog posts that shown many different ways to approach incremental deployments for Sitecore since v8.2, I would just like to show everyone my way instead. Keep in mind that this approach is nothing really crazy, and it is just a very standard approach leveraging Azure Resource Manager to deploy in any type of Azure Cloud Native resources.

Main Incremental Deployment Objectives

The objectives are as follows:

1. Deploy into a clean Azure Web Apps staging slot
2. Modules are included as part of deployments. In my case, Sitecore Powershell Extensions, Sitecore Experience Accelerator, Sitecore Headless Service, Coveo for Sitecore Connector, a third party DAM connector
3. Deployment time needs to be as quick as possible. That means all relevant Azure App Service must be deployed into at the same time.
4. The process of stripping out the databases, and applying Sitecore Cargo Payload (SCCPL) Packages must be clearly shown and demonstrated to everyone with full transparency

The only way to achieve all of the above objects, is to Pipeline All The Things.

Pipeline All The Things

Prepare the Sitecore Packages, Modules and Cargo Payload Packages Build Pipeline

There are already many blog posts out there which describes the process of stripping off the dacpac files, so I would refer this step to those blog posts instead.

The structure of the SCCPL packages is described in Sitecore’s official documentation https://doc.sitecore.com/xp/en/developers/sat/28/sitecore-azure-toolkit/the-structure-of-an-sccpl-transformation.html

I would create a folder for each SCCPL that needs to be applied, then follow the folder structure with the appropriate files, the XDT transform required, and finally the IOActions required. Then, the pipeline would run the New-SCCargoPayload command to generate the .sccpl file.

Both SXA and Headless Rendering services include their own SCCPL package files already in both the Content Management and Content Delivery package files. They are located inside the App_Data\Transforms folders.

With all the packages being stripped off the dacpac files, and the SCCPL packages generated, an additional step would then Sideload the SCCPL into those Sitecore Web Deploy Package (SCWDP) files to perform the appropriate file actions.

The steps above should generate all the baseline packages and modules required for a no database, files only approach into an Azure App Service Slot, which can be reused for any environments required for the whole Software Development Lifecycle (e.g. Dev/Test, Staging, UAT, Production etc).

I will outline the exact steps in my pipelines to prepare for everything above. Note that the steps to Delete certain things are required as there is limited storage space on ephemeral build agents

1. Install SQL Server 2012 T-SQL SciriptDom (x64)
2. Install SQL Server 2012 System CLR Types (x64)
3. Install SQL Server 2012 Data-Tier Application Framework (x64)
4. Download all Sitecore package files from Sitecore and other third party web sites
5. Extract Sitecore Azure Toolkit
6. Delete Prerequisites Installers
7. Delete Sitecore Azure Toolkit Zip file
8. Copy Sitecore provided SCCPL packages
9. Generate custom Sitecore Cargo Payload for CM
10. Sideloading ALL Sitecore Cargo Payload into CM SCWDP
11. Publish Sitecore Cargo Payloads for CM to artifact
12. Generate custom Sitecore Cargo Payload for CD
13. Sideloading ALL Sitecore Cargo Payload into CD SCWDP
14. Publish Sitecore Cargo Payloads for CD to artifact
15. Publish Sitecore License File to Artifact
16. Duplicate Sitecore SCWDP and Module SCWDP files
17. Strip out Database for duplicated Sitecore SCWDP and Module SCWDP files
18. Publish all SCWDPs to Artifact

Deploy Prepared Packages and Solution Files into Staging Slots

The following Azure Resources are required to support incremental code deployment:

• Azure Blob Storage — this is used to house the various zip files for Azure Resource Manager to tap into during deployment. My preference is all files require SAS tokens, and the files should delete themselves after X days
• Azure Key Vault — this should store the following secrets for each environment. Sitecore Admin Password, SQL Server Login, SQL Server Password.

It is important to note that the correct Azure Governance policy, which may have been defined from the Cloud Centre of Excellence (CCoE) should be applied correctly for the resources above.

1. Provision the Sitecore environment via Azure Marketplace
2. Store the Sitecore admin password, SQL Server Login, SQL Server Password into Azure Key Vault
3. Take note of the Resource Group name that has been provisioned as that is important

One important part of the Sitecore ARM template, is that a lot of passwords are generated from the initially provided SitecoreAdminPassword when the environment is first provisioned. Rob Habraken has a detailed blog post on modifying the ARM templates to take the SitecoreAdminPassword as a parameter.

Blue Green Sitecore Deployments on Azure

There is one really cool part of ARM Template property called addOnPackages . It has an array that can be specified with various Zip files to be deployed into. I have opted to fully take advantage of this feature, by first specifying the main package Uri to deploy first using the packageUri property (which is a sibling property of addOnPackages), which is the main Sitecore package zip file installation. Inside the addOnPackages property array, then specify Sitecore Powershell Extensions, Sitecore Headless Services, Coveo for Sitecore connector and other packages that are required.

By utilising the approach above, someone externally can clearly see what exactly is being deployed into the staging slot. I have provided a link to the generated ARM Template with a specific environment parameter file, which references an Azure Key Vault.

This layering approach is also very similar to adding layers of instructions in a containerised environment.

Final Words

A lot of man hours and team work have been used to set this process up, so that it can be fully transparent to any external person who wishes to audit the process.

A lot of Powershell scripts with Azure CLi were used in this process, to ensure that it is repeatable in most ephemeral build agents.

If anyone in the community wishes a full walk through via a video call, please reach out as I am more than happy to setup a call to walk through the mountains of Powershell Scripts and Azure YAML Pipelines.