Sitecore Zero-downtime deployments – Part 2

Sitecore Container based CI/CD Flow

With modern and mature DevOps, we all want smooth, sleek and painless automated deployments with zero-downtime. Sitecore deployments are no exception. Have you embraced zero-downtime deployments? This is not a new topic. If you look around Sitecore community, you see an odd question popping here and there regarding this topic.

The journey towards achieving zero-downtime deployments for any application in fact starts with your code base. So, in this series of blog posts, we will refresh ourselves on concepts like “Code Freeze” and the CI/CD process before deep diving into implementing Sitecore zero-downtime deployments.

• Sitecore Zero-downtime deployments – Part 1 (Do we need code or content freeze?)
• Sitecore Zero-downtime deployments – Part 2 (this post)
• Sitecore Zero-downtime deployments – Part 3 (Blue-Green deployment strategy)
• Sitecore Zero-downtime deployments – Part 4 (Sitecore PaaS/AKS Zero-downtime deployments)

Sitecore container based CI/CD flow

Sitecore Deployment options

Sitecore can be deployed to the cloud using IaaS, PaaS or Containers.  Microsoft Azure cloud  is preferred, although you can deploy to other providers like AWS

• IaaS makes use of Virtual Machines
• PaaS makes use of Azure App Service to run Sitecore web apps
• Containers makes use of Azure Kubernetes Service (AKS)

How working with containers is different

When working outside of containers, you would typically build your application and then push it directly to the IaaS or PaaS instances hosting them. Using Containers changes this process slightly. The infographic below captures this process in detail

Sitecore containers CI/CD process summary

Explanation of the CI/CD process

1. So developers make changes to the codebase.
2. They then commit their changes into the repository, in this case stored in GitHub
3. An Azure DevOps Pipeline monitors this repository and triggers a new image build each time there is a commit into the repo
4. These images are built by Azure DevOps and the new image version is pushed into an Azure Container Registry (ACR) instance
5. We have Other triggers for a base images that might have changed. For example, an update to the base Windows image or Sitecore image that can also trigger a new image build to occur. This is where the CI part of the process ends. We now have our new images built and available for deployment.
6. So this is where the CD element starts. A release element is going to execute to start the deployment process.
7. The first thing the CD element does is to push the new version of the k8s Specs into AKS, including pinning the deployments to the unique tag of the new images.
8. AKS will now connect to the ACR instance to pull down these new images and build new deployments based on them.
9. Of course any Sitecore deployment isn’t complete without a push of the content changes. Once the specs have been deployed the content is then also pushed to the CM instance running in AKS and a publish is executed.
10. Once this has happened your end users can now browse the site and interact with the new containers running in AKS.

Hopefully, these blog post help you understand how to manage Sitecore Container based CI/CD process going forward. If you still struggling, engage your digital partners to look for long term solutions.

Next steps

In the next blog post in this series, we will look at BLUE-GREEN deployments and how to leverage this strategy to implement Sitecore Zero Downtime deployments.