blastic logo

Sitecore 10: the technical low-down

by Koen Heye , Sep 10

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!

Sitecore Containers

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.

Speed up development setup time 

We are really excited about this: 

  1. No installation is needed:everything you need is already embedded in the Sitecore Docker image.

  2. We won’t have to worry about the OS anymore, since it is abstracted away in the containers.

  3. 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.

  4. 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 with Sitecore 10

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!

Sitecore Serialization – Sitecore CLI – Sitecore for Visual Studio

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.

Setting up Sitecore Serialization

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.

  • Both are YAML file types

  • Doesn’t have the Database field

  • Does have some default additional serialized fields in Revision id, Updated by and Updated datetime.

Ok, so now we know what it does. But how can we use it and create those serialized files? There are 2 options: The Sitecore CLI and a GUI for Visual Studio.

Using Sitecore CLI to interact with Sitecore

The Sitecore Command Line Interface is a new tool that was created to improve the Developer Experience with Sitecore 10. And specifically, for usage with serializing Sitecore items. The CLI tool will receive additional functionality in the future. But for now, it can be used for serialization and for publishing. 

  1. Install the CLI first

  2. After that, you can use the CLI to login:

1.  Sitecore login --authority https://<identity authority> --cm http://<Sitecore instance> --allow-write true. This will launch a popup where you can login as a user into the Sitecore environment:

 

2.  Sitecore login --authority https://<identity authority> --cm http://<sitecore instance> --allow-write true --client-credentials true --client-id <client id> --client-secret <client secret>

This allows you to login with a client-credential. Which has to be configured in the Identity server first. Which of course can also be used by CI/CD pipelines to interact with an environment. Then you can send any available command to it.

Example of Sitecore ser info:

Using SVS to interact with Sitecore

The CLI is not the only way to interact with a Sitecore environment. There is also a plugin available in Visual Studio itself which you can use, called SVS: Sitecore for Visual Studio. The only requirement is, is that you have a license. Which is included with the Sitecore TDS license. Installing this plugin will provide VS with an additional window called: Sitecore Module Explorer.

This Sitecore Module Explorer allows you to manipulate the configuration of which items need to be serialized. And lets you Pull or Push specific item folders.

On the right side, you can see an interactive window to manage the module.json files.

A little drawback with the current system is that when adding configuration, you have to add a path to the Sitecore item manually. There is no easy way to select an item from in Sitecore itself. SVS will certainly change and get updated later.

ASP.NET Core

Sitecore has been leveraging ASP.NET Core in the past by having the Publishing Service run on it for example. And Sitecore Host is also based on the Core platform, which is used for Universal Tracker and Sitecore Identity.

So Sitecore is moving more and more towards .NET Core. With Sitecore 10, a new development option is also available: the ASP.NET Core SDK. This is a Headless option that is now available beside the ones already usable with Sitecore JSS: Vue, React, React Native and Angular. Those are front-end frameworks specifically tailored for front-end developers.

While ASP.NET Core SDK tailors more to back-end developers and allows us to work with the latest and greatest .NET Technology.

You can use the Helix ASP.NET Core example as a testing environment which you can setup locally with the new Sitecore Docker containers. Here is an example of the ListProducts view:

It is great to have the option to develop Sitecore applications in ASP.NET Core while still being able to leverage the Experience Editor in Sitecore. It should allow us to setup demo environments more easily. But since it’s new, we’ll need some time to adopt!

Final thoughts

Sitecore 10 brings a revolution of new changes to the platform and we are excited to start using Docker which is now officially documented and supported.

The Sitecore CLI seems like a robust tool which will evolve into a Swiss knife allowing you to interact with any Sitecore environment to perform numerous Sitecore tasks.

Some useful links

Can't wait to get started with Sitecore 10? Here are some useful links for you:

Need a little bit more help with the implementation of Sitecore 10? Don't worry - we got you covered. Our Sitecore experts are happy to help!

Let's collaborate

Contact us