Author: Jitendra Soni

SCS is pretty new, and there are a few basic recommendations while doing the first setup, In this blog, we will discuss those settings and options.

This blog has split into three parts, and this is part 3.

• Part 1- Sitecore 10 SCS- Basic View
• Part 2-  Compare SCS with Unicorn
• Part 3-  SCS Best practices and Q&A

1. Configure the relative serialization path correctly. In Microsoft NTFS the maximum length is 240. In SCS the content serialization path size limit is defined in the settings, by default, the value is 100.

{
  "$schema": "./.sitecore/schemas/RootConfigurationFile.schema.json",
  "modules": [
    "src/*/*/*.module.json"
  ],
  "serialization": {
    "defaultMaxRelativeItemPathLength": 100,
    "defaultModuleRelativeSerializationPath": "items"
  }
}

The maximum relative item path length = the file system maximum path and file name length – (the base path length + the serialization path length). for more details, please follow this link – Configure the maximum relative item path length

2. Define the hash and alias for relative serialization path – Hashing to shorten paths and aliases and to make it human readable.

It’s super important for two purposes. One is to mitigate the risk of serialization path, and second is define the structure of the project like we can define common aliases for the site.

Relative path is combination of four section (Base path + serialization path +include path content item path) , for example

C:\Users\jsoni\Sitecore\Project\src\Sites\ +  serialization\ + content\ + Home\Products\P1\test.yml

define the alias

"rules": [
  {
    "path": "/Home/Products/P1/test",
    "alias": "alpath"
  }
]

3. Sequence is most important while defining the module.json – As a rule of thumb with Sitecore, all the dependencies should be defined first, for example before defining the content we have to define the templates, layout and rendering etc.

for example

{
  "namespace": "Feature.Hero",
  "items": {
    "includes": [
      {
        "name": "templates",
        "path": "/sitecore/templates/Feature/Hero",
        "allowedPushOperations": "createUpdateAndDelete",
        "scope": "itemAndDescendants"
      },
      {
        "name": "layouts",

        "path": "/sitecore/layout/Renderings/Feature/Hero",
        "allowedPushOperations": "createUpdateAndDelete",
        "scope": "itemAndDescendants"
      }
    ]
  }
}

4. Don’t forget first-match-wins principle while defining the IA or base principle of the content sync strategy – this rule says when a content item matches a rule, all subsequent rules are ignored:

As per the Sitecore recommendation, we need Keep the following things in mind when we configure rules:

• No path overlapping, If you follow the Helix principles I’m sure it will be much easier, otherwise it can be very hard to identify any path overlaps.
• Again, Parent rules will override the child rule, example if you have mentioned a rule on parent item node, It will override any child rule configuration.
• Rule scopes cannot be more inclusive than the root scope. For example, if the root scope is ItemAndChildren, the rule scope cannot be ItemAndDescendants.
• The alias property in a rule replaces the root name property (the folder name in your file system) for this particular rule.
• If you have configured an alias property and a scope property with an ignored value, the scope is used. Content items scoped to be ignored are not influenced by aliases.

For more details, please follow below links

• Sitecore Content Serialization structural overview
• Sitecore Content Serialization configuration reference

I hope this blog will help you to think of a few fundamental considerations while starting to work with SCS on Sitecore.

Unicorn was the most popular plugin for content serialization. It was very straightforward and well managed; all the documents were very descriptive and easy to understand. Now we have Sitecore Content Serialization (SCS), I think we must understand what has changed. Are we losing or gaining any functionality? what changes are required to our existing setup? Re there any changes in terminology etc?

This blog has been split into three parts, and this is part two.

• Part 1- Sitecore 10 SCS- Basic View
• Part 2-  Compare SCS with Unicorn
• Part 3-  SCS Best practices and Q&A

Below is the high-level comparison between Unicorn and SCS.

1. SCS has an additional Visual Studio plugin to manage Content.

SCS configuration is based on JSON files and Unicorn configuration is based on XML.

The configuration file naming convention is different. The SCS configuration file names contain modules for identification and Unicorn configuration contains serialization – Although this is configurable.

The initial setup is different. For SCS we have to setup the package and to enable the CLI it’s required to install the packages.

Difference in global/shared configuration

Difference in project level configuration.

SCS provides more flexibility for rule based configuration, for each feature we can define a rule and each rule has the option to define the path, scope and allowed PushOperations etc.

There are changes in the configuration.

When using Unicorn we used to define the dependencies and extends options

<configuration name="Feature.Demo" description="Feature Demo" dependencies="Foundation.*" extends="Helix.Feature">

With SCS, we need to handle it while defining the feature itself and any overlap, for example if there is any specific overlap we need to make sure to put the most specific rule first.

Rule of Parent’s path override rule of children’s and dependent path.

Overall, I can see the SCS configuration is much easier and more flexible. However, I’m still looking for an option for pattern-based formats in SCS.

I hope this comparison will provide a basis to understand the difference between Unicorn and SCS.

Sitecore has introduced Sitecore Content Serialization (SCS) as part of version 10. In this blog, I will explain the basic concept of serialization and compare all Unicorn features, followed by steps for the basic setup and best practices.

This blog has split into three parts, and this is part 1.

• Part 1- Sitecore 10 SCS- Basic View
• Part 2-  Compare SCS with Unicorn
• Part 3-  SCS Best practices and Q&A

Part 1 – Sitecore 10 SCS- Basic concept

Let’s first try to understand the definition, Serialization is the process of translating a data structure or object state into a format that can be stored (for example, in a file or memory data buffer) or transmitted (for example, across a computer network) and reconstructed later (possibly in a different computer environment) – Wikipedia

Sitecore Content Serialization (SCS) is a system for serializing, sharing, and deploying content items, as well as keeping them in version control – Sitecore

Now, we know the definition of serialization. I remember with the Sitecore 6.X Serialization guide we had an option to serialize the item tree and restore it, there were additional options to configure the serialization based on the events like item saved, created, deleted etc. and we were using SVN to store those serialized files.

Growing of TDS (Team Development for Sitecore) foundation

TDS was beneficial to manage the project and item files. I used TDS a lot with Sitecore 6.X versions. We were also using this as part of the deployment process as the underlying TDS was using the MSBuild project file to group the Sitecore items into a deployable project. Additionally to that, it has the below features which are not part of SCS.

• File deployment into a local Sitecore instance
• Web Deployment Package (WDP) generation
• Code generation
• Validators
• Environment Validation

Note – Paid license is required for TDS and the cost was around USD 400

In my opinion it’s the end of the TDS era.

Growing of Unicorn (/unicorn.aspx)

Unicorn is a Sitecore utility and it is open source. It solves the issue of moving templates, renderings, and other database items between Sitecore instances. TDS is a monolithic product with commercial support, and marketing does a lot more than just serialization. Unicorn is relatively simple, free and open-source, and does one thing well.

I prefer using Unicorn instead of TDS. Generating the TDS code was not that easy and always needed to take care of the partial class, unnecessary field generation, etc. We can set up the template class following the helix principals.

For more details about the setup, Here is my blog post – Sitecore – Unicorn setup, patterns and tips.

In my opinion Sitecore content serialization would be a replacement of Unicorn.

Sitecore Content Serialization – Future with Sitecore 10 and current focus

SCS will do the out-of-the-box item serialization that lets you automate the synchronization of item changes. It has two options one is using the command-line interface (CLI) and the second Sitecore for Visual Studio (SVS)

Note – for using SVS it’s required to get the license and TDS and SVS are both offered under the same license.

Basic Settings and configurations

Out of the box there are three options to serialize content, The default serialization format (.Item)

• Manually serialize, update, and revert items in the Content Editor.
• Use Sitecore event handlers to automatically serialize items.
• Use the Sitecore service page to serialize, update, and revert a whole database.

Item format

YAML format – using Unicorn and Sitecore content serialization.

This article is the first part to explain the basics of serialization, in the next Part 2- Compare SCS with Unicorn, I will explain the difference between Unicorn vs SCS setup.

I hope this article will help you to understand the basic concept of serialization.