Sitecore, Docker, and Continuous Integration

With the release of Sitecore 10, we introduced support for running Sitecore inside Docker Containers. This enabled a fantastic development experience, allowing you to create and remove entire Sitecore environments from your local machine quickly and easily. The days of long, drawn-out installations are finally a thing of the past!

The development community is understandably excited about this change to working with Sitecore. But what happens when you move past development and want to start deploying your solution to your non-production and production environments? Well, just like when you work outside of containers, you will want to configure a Continuous Integration (CI) pipeline to automate this process for you.

Watch the video accompanying this article, which includes demos of these concepts on our Discover Sitecore YouTube channel.

When configuring a CI pipeline for containers, things are set up a little differently. 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.

When working with Containers, the aim of your CI process is to build a new set of images and push those to your Container Registry. With this action complete, the CI phase of your deployment is done.

The good thing about this CI phase of the deployment is that we can leverage the Docker Compose we use for our local development setup to also automate our image builds. The great aspect about this is that we can use the same instructions we used on our development machine to build the images that will be used in our non-production and production instances. This increases the confidence you have in what you're deploying while decreasing the “It works on my machine!” issues we all know.

When working with containers, the concept of image tagging is critical, as it allows you to control which version of your application is deployed to which environment. There are two different types of image tags when working with Containers: Stable tags and Unique tags.

Stable tags

Stable tags, represented by the green boxes above, are primarily used for base images — you inherit from them to build your images, and they're rarely used for deployments themselves. The reason? They change over time. If you pull the same stable image tag today and then again next week, you could actually get two different images. This is because the images using these tags are re-issued over time to represent versions updates, or base image changes.

Unique tags

Unique tags, represented by the dark grey boxes above, are primarily used for deployments, especially in environments that scale to multiple nodes, or running inside of an orchestrator like Kubernetes. This is because the image behind a unique tag won't change, giving you confidence that the image you pull today is the same as the image you pulled at a previous time.

(If you're looking for more, Microsoft has a good write-up on the difference between these types of tags here.)

Image updates can be triggered for different reasons, but the most common two are a code change or a base image update. A code change would require your images to be rebuilt to include the changes made to your codebase. 

With base image updates, your codebase hasn't changed while one of the base images you depend on has been updated. This could be one of the Sitecore images or maybe one of the base MS images. This also requires a new image to be published to include important updates, such as bug fixes and security updates.

Once you build your images, the last action you need to perform in your CI pipeline is to push them out to a container registry, like Azure Container Registry. This makes them available to other developers on your team and also means they're available for use in your non-production and production environments.

If you want to see an example of how to configure a pipeline like this, you can take a look at the MVP Site project. This has a fully functioning CI/CD pipeline that you can base your own off of. You can see the YAML configuration for use in Azure DevOps here.