Where are Sitecore's paper plates?

07 Nov 2024 🔖 web development
💬 EN

I’m used to Sanity CMS, which inherently treats the structure/schema in which you store content and present it to authors as an immutable consensus that you implement by hand-authoring code and tracking your changes with source code version control.

I know Sitecore CMS predates it a lot. Still, my understanding is that Sitecore is moving away from being a Wordpress-like “headful” CMS that also serves traffic to your web site, and into being a “headless” CMS that only stores your data and makes it easy for authors to edit.

• They started the journey to “headless” backends well over half a decade ago, it seems.
• They’ve finished that journey with the “XM Cloud” edition of Sitecore CMS (it only runs as a “headless” CMS backend).

So … where are all the blog posts helping people think about configuring Sitecore the way you configure Sanity?!

---

Never hand-configure a shared system

I’m a big fan of the philosophy that if there is ever a possibility that more than one person might ever need to share a system, then that system’s settings should never be configured by logging into the system and changing things by hand.

Instead, the desired settings should be typed into plaintext files that are tracked with source code version control.

Once configurators’ “hey, this would be a neat change” edits to those plaintext files have been merged back into the version control system’s long-lived branch…

…then a CI/CD pipeline should be responsible for reading those plaintext files and accordingly updating the shared system’s actual settings.

Paper plate servers

When the shared system is a server, people in the DevOps industry tend to refer to servers configured this way as “immutable workloads.”

I’ve also heard people call this treating the servers like “paper plates, not fine china” (or like “cattle, not pets”).

However, I don’t think it necessarily has to only refer to the way a server’s operating system is set up, the software installed onto the server, etc.

Paper plate clicky systems

I like applying this manner of thinking to all kinds of “computer systems that more than one person can share.” Here are 3 examples of my philosophy with “clicks, not code” tools I’ve worked with in the past:

1. Never ever ever alter any “Settings” in a Salesforce production org or sandbox. Instead:
   • Spin up a “scratch org” and edit the settings there.
   • Use DevOps Center or the SFDX command line interface to save your work into your company’s shared git repository.
   • Let a CI/CD pipeline (perhaps with the SFDX CLI as part of the commands it runs) or DevOps Center do the actual work of editing Settings in an appropriate Salesforce production org or sandbox on your behalf.
2. Once you flip on the setting to let Azure Data Factory auto-synchronize the way you’ve configured it to and from your company’s shared git repository, lock things down so that you can never ever ever again accidentally alter any configuration when the ADF Studio is showing that you are working against the “main” or “master” branch of that repository.
3. Never ever ever log into a content management system’s (“CMS”) administrative portal and change things around. Lock yourself out so you don’t get tempted.
   • Sanity CMS doesn’t even offer you an administrative portal where you can do things like add a field to a data type’s schema in the first place, which is awesome!
   • In a more clicks-based CMS like Sitecore CMS, you’ll have to approach things more like Salesforce admins do these days.
     • Furthermore, Sitecore CMS doesn’t offer anything comparable to Salesforce’s “scratch orgs,” so you’ll have to roll your own ultra-short-lived (ideally hours, maybe a few days) equivalents to Salesforce’s “scratch orgs” on your own computer using the “Sitecore CLI” and “Docker Desktop.”

---

Ideal developer workflow

The way I see it, anyone who wants to add a “fax” field to a “contact us” Sitecore definition item, at a company where there are three Sitecore CMS environments (development, staging, production), should:

1. Create a new branch in the git repository that stores your company’s “backend” Sitecore CMS configuration settings, if one hasn’t already been created for the work you’re about to do (maybe you’re pair-programming with a colleague and they just created it 5 minutes ago).
2. git pull a copy of that branch onto your own computer’s hard drive.
3. Use that code to build and run Sitecore CMS “backend” simulation on your own computer.
   • Note: might require Docker Desktop to facilitate turning your laptop into a pretend web server.
   • Note: to ensure that anything you do while clicking around this simulation will persist to your computer’s filesystem, you’ll probably want to also run something like:

       dotnet sitecore login --cm https://cm.localhost/ --auth (blah blah)
       dotnet serialization watch
     

4. Log into the CM server’s web portal within the simulation, using credentials that are allowed to edit definition items in the simulation.
   • (Hopefully, you’ve set your security roles up so that those credentials can’t edit any definition items in the real development, staging, or production CM web portals. Simulation CM portals only.)
5. Do your clicks to add the “fax” field, save your work, shut down your simulator so it is no longer running.
6. Commit and git push the changes you made (which serialized onto your own hard drive thanks to dotnet serialization watch) back into the company’s shared Git repository.
7. Do appropriate pull requests, peer review, etc. within the company’s shared Git repository. Don’t forget to delete the branch you created once your changes get merged into a longer-lived branch of the repository.
8. Let a “CI/CD pipeline” do all of the work to actually add the “fax” field to development, staging, and production, since you’re locked out of doing it by hand. It’ll run commands against each environment such as:
   1. For deploying things that require click-based configuration (e.g. schema / definition item changes like adding a “fax” field):
      1. dotnet sitecore cloud deployment create --environment-id (dev/stg/prd) --upload (if XM Cloud)
      2. dotnet sitecore login --cm (dev/stg/prd) --auth (blah blah) --allow-write true (if XP)
      3. dotnet sitecore cloud login ... (if XM Cloud)
      4. dotnet sitecore serialization push (if XP)
      5. dotnet sitecore publish (if XP)
   2. (If XP:) Deploying anything else left that requires more traditional hand-coding-based configuration (e.g. if you had to upgrade the version of .NET that the CM server is built with and tweak source code to match):
      1. dotnet build
      2. az webapp deploy --resource-group (dev/stg/prd) --name (dev/stg/prd) --src-path (output of dotnet build)
         • (for example, if your real dev/stg/prd CM servers are hosted on Azure App Service – change to AWS commands, etc. as appropriate)

---

Feedback welcome

1. What do you all think out there in the Sitecore administrator / backend developer community? Is this indeed ideal in Sitecore-land as of late 2024?
2. If it were ideal, then would tools for moving configuration directly amongst development, staging, and production (e.g. TDS, Razl, Unicorn) even still be needed by backend admins & developers? Or would they pretty just need Docker Desktop and great training on commands like dotnet sitecore serialization watch?
   • (It looks like some of these tools aren’t even meant to be used with XM Cloud in the first place, and from what I can tell, people should be slowly reconfiguring their existing XP servers to behave exactly the way XM Cloud instances behave anyway, so it seems like one should use an XM-Cloud-ready development/configuration flow, even if still an XP customer?)