By Koen Heye, 10 September 2020
While Sitecore 10 has been out for a few weeks now, it’s time to focus on the technical side of the improvements this version brings when compared to Sitecore 9. We'll discuss the following topics: Sitecore Containers, ASP.NET Core SDK, Sitecore CLI and Sitecore for Visual Studio. Let's dive in!
Installing and hosting Sitecore 9: let’s recap: you could install it on a self-managed IaaS environment, you could also leverage Azure WebApps and of-course you also have the option for Azure PaaS.
Beside those, there was a community driven solution for creating Sitecore Docker images. And last year Sitecore was able to provide support for environments hosted in said containers. Given that the issues were reproduceable in a non-containerized environment.
This was already a good indication that Sitecore was moving towards containers. With Sitecore 10, they now provide documentation and officially support images for deploying a solution in a containerized environment. Making it a lot easier to deploy your Docker containers to, for example, Kubernetes.
An image is a package with all code and dependencies. It is basically a blueprint for creating a container. Often, an image is based on another image, with some additional customization. An image is immutable once it has been created.
Another big advantage is that it provides more flexibility on where to host your environment in the Cloud. Do you want to run containers in Azure or would you prefer Amazon instead for example?
And of course, running containers will reduce the infrastructure cost when compared to an environment with multiple virtual machines, because the OS kernel is shared between containers and no longer duplicated each time.
So Sitecore now provides an official feed with base images. This was previously not possible with the Community solution where you had to create your own ones.
This official feed provides public images for Sitecore XM, XP0, XP1, JSS together with images where Sitecore doesn’t provide support. Those are labeled as nonproduction: such as Solr, SQL and Redis cache. These are more intended as non-production developer images, and you’ll have to create your own base images if, for example, you want to use a custom database in SQL or custom indexes in SOLR.
We are really excited about this:
No installation is needed:everything you need is already embedded in the Sitecore Docker image.
We won’t have to worry about the OS anymore, since it is abstracted away in the containers.
We can spin up the required containers and get going. Sharing between colleagues is easy since the environment is a complete configuration-based setup. And thus, shared easily.
It is easier to manage dependencies. For example, every Sitecore version has a supported SOLR version. When working for multiple clients who are on multiple Sitecore versions – as a developer myself – we have to install and maintain different SOLR versions.If SOLR is abstracted away in a container, we also don’t have to worry about that.
Example Docker XM setup
In the image above you can see a local XM scaled environment. You can of course also do XP, just spin up the right containers.
The new Traefik reverse proxy role allows you to run all these instances easily and work on multiple projects at once, allowing the reverse proxy to handle the complexity of finding the correct container instance to return to the browser.
The ability to use containers allows us to have multiple options for the local development setup and additional hosting options for the acceptance and production environments of our clients.
Getting started locally was a breeze and is documented very well by Sitecore. The simplified steps:
Start by preparing your environment by installing Docker Desktop for Windows;
Then clone the Docker Examples repository;
Make changes to the .env file for your environment variables (Sitecore license, passwords);
Install Sitecore DockerTools PowerShell module which contains various helper methods;
Run docker-compose up -d
Docker-compose will start the containers based on their image. If the containers already exist, it will check if the configuration or image was changed. And if that is the case, it will recreate the container. -d indicates that the containers should in in the background.
What happens the first time when you run docker-compose up? It starts downloading images. Which takes way longer than to start the containers itself. Just be prepared to have a bit of patience the first time you want to spin up Sitecore with containers.
This example shows the result for the Sitecore Helix example with new ASP.NET Core rendering container, which can be downloaded here. You can read more about this down below!
Let’s talk about Sitecore Serialization and the new tools that Sitecore provides to work with them.
Serialization is taking an item from the Sitecore Content Tree, saving it on your hard disk and providing us – the developers – the ability to synchronize it to another Sitecore instance. So, it’s used to move items from our local environment to acceptance and production. It also allows us to write or generate code more easily to interact with those items. Like reading out fields.
It has only been a year and a few months since Sitecore acquired Hedgehog. Which of course included the Hedgehog TDS tool: Team Development for Sitecore. Another popular tool used for item synchronization is Unicorn. The new Sitecore serialization basically combines best of both worlds.
You can still use Unicorn though. So projects upgrading from a previous version of Sitecore that use this, can easily be migrated to Sitecore 10.
You must start by defining which items you need to serialize. This is done in a module.json file. Which is very similar to how Unicorn works. So if you apply the Helix principles and have multiple foundation/feature/project projects, each will have its own configuration file defined.
In this module.json file you can include or exclude paths. It also supports aliasing, which solves the problematic Windows issues regarding paths that are too long. The order is very important. Templates need to be defined before other items that rely on that template.
Example of the products.module.json file from the helix-basic-aspnetcore example project:
This configuration will result in serialized YAML files which are slightly different from the Unicorn format. Here on the left you have an example of a serialized item in Unicorn of the Hero Banner template. On the right you have the same template with Sitecore Serialization.