When I started working with the XM Cloud setup on my local development environment using the Docker container images provided by Sitecore, I added some content serialization config files and enthusiastically started creating data templates, rendering items and demo content. I then had to switch to another project for a bit, stopped my containers and got back to my XM Cloud containers a little later. Only to find that all of my newly added content was gone… what happened?

“Hey where did my Sitecore items go?”

At least two developers on our team..

The XM Cloud template or starter kit xmcloud-foundation-head only contains one Sitecore serialization config file to start with (src/renderinghost.module.json):

So the following comment in the default .\up.ps1 script does make sense:

But in fact, it does not only push the rendering host configuration, but all serialized content! It just performs a full push on all configured serialization modules, unconditionally.

The issue

What that means, is if you add additional SCS configuration to serialize specific content items, be it either test content in your development environment, or data templates to build up your implementation, you run the risk of losing your content when starting up your containers, if you didn’t deliberately perform a pull operation before stopping them.

To demonstrate a simple workflow and common use case, let’s add a simple new module called templates-renderings.module.json to sync all of your own templates and rendering items:

This is cool, because you can now easily keep track of all templates and renderings in your repository, pair them with the accompanying code of your feature branch containing renderings and any other relevant changes, and share them with your team members or push them to your XM Cloud environments.

But this also means, that if you push your items from your repository to your database without syncing (pulling) newly added items first, it actually deletes your newly created content. Because of the somewhat hidden ser command in your startup script for your containers, you are risking losing your content if your laptop crashes, if you need to reboot or if you are switching projects.

Suggested fix

First of all, you could make it a habit to always pull in your changes from your local dev environment before you stop your containers. But that’s easy to forget and not a very robust solution.

A solution could be to use the CreateAndUpdate operation instead of the CreateUpdateAndDelete operation, so that any content that isn’t synced yet will always remain in your database. But that could pollute your local development environment over time, and also would prohibit you from pushing changes to the XM Cloud environments where you clean up Sitecore items, removing old templates or renderings that are no longer used, for example.

I would suggest simply removing the serialization push from your startup script and to manually perform a dotnet sitecore ser push command whenever you desire. There’s no reason to combine the act of starting up your containers with pushing your local synced content into your containers.

Another option would be to specify the serialization command to actually only push the rendering host configuration, and make the command match the comments, like so:

You can look up more advanced commands in the documentation of SCS, it is a versatile tool that can really help in setting up a robust content serialization strategy: https://doc.sitecore.com/xp/en/developers/101/developer-tools/the-cli-serialization-command.html#the-push-subcommand

I’ve created a pull request for this small change to the XM Cloud foundation head repository and encourage you do to the same whenever you run into something. Even a small improvement like this can help!

---

Edit: as suggested by Chet Povin on my LinkedIn post when sharing this blog post, a possible solution also could be to include the dotnet sitecore ser watch command in your up script. This automatically pulls all changes within your database to your filesystem. This way the currently embedded push command in the script doesn’t wipe out any unsynced content. Though still I don’t see a functional correlation between starting up your containers and pushing all of your synced content into your database, so my own preference would be to remove it or it make specific for only the RenderingHost module.