Separate editing hosts in SitecoreAI - use Sitecore CLI for extended options

Recently, SitecoreAI introduced the separation of authoring environment (the content management platform) and editing hosts. Currently, you can activate it as a preview feature.

This will allow you to use different repositories for the authoring platform and for the head application used for editing host, which is something we have really been embracing.

As a consequence, in the list of environments you will now see authoring environments as usually and then editing hosts listed on their own.

You can of course create the editing host from the SitecoreAI Deploy UI. However, as usually, you will need to use the feature to link to repository and branch for creating it from the UI, those fields are mandatory.

For connecting to a GitHub hosted repository, it is working ok. There is a GitHub App for Sitecore Deploy that you will add to your repository and allows Sitecore Deploy to subscribe for commits and read the repository for building.

You can also link to an Azure DevOps based repository, however, the underlying connecting will be using the permissions of the user, so if that employee changes job or similar, you will need to redo the connection. If you are using anything else for source control such as GitLab or BitBucket, then SitecoreAI cannot connect to your repository and you have to manage this with your own pipeline.

Create environments with Sitecore CLI

To be able to deploy without linking to source repository, you would also want to create the environment without linking to a repository. This is possible by using the Sitecore CLI.

In Sitecore CLI, at least from version 6.0.23, there is now the option to create both environments and editinghosts:

Previously, you would just do something like dotnet sitecore cloud environment create --project-id $yourProjectId --name xmc --prod to create an authoring environment, and in xmcloud.build.json you would reference the editing host and both will be deployed.

When using separate editinghost environments, the command above will actually give a failure indicating that Environment type '' cannot be created in the project. Instead you will need to add a new --cm-only parameter, to indicate that it is just the autoring parameter. So the new command to create an authoring environment would be (include or leave out the --prod if you need production SLA and replace the name and project id with your actual values):

1

dotnet sitecore cloud environment create --project-id ${yourProjectId} --name xmc --cm-only --prod

Next you will need to create the editing host.

The editing host is linked to a cm environment. The command above to create an authoring environment will output the info about the environment and one of those properties are the id.

The name of the editing host is also important, for deployment of the editing host, there is still a need for an xmcloud.deploy.json as before and this file contains the definition of the rendering hosts with the name and the path. That name in renderingHosts object have to match the name of the editing host.

Eg. if you have the environment id from before in a variable called envId and you xmcloud.build.json is something like

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "renderingHosts": {
    "website": {
      "path": "./headapps/website",
      "nodeVersion": "22.11.0",
      "jssDeploymentSecret": "...",
      "enabled": true,
      "type": "sxa",
      "lintCommand": "lint",
      "buildCommand": "build",
      "runCommand": "next:start"
    }
  },
   "authoringPath": "./authoring"
}

Then you will create the corresponding editing host by running

1

dotnet sitecore cloud editinghost create -n website -cm $envId

Again, the environment for this editing host has an id, let’s save this in a variable called `edtEnvId´…

Deployment with Sitecore CLI

Next, you will make the actual deployments from your pipeline. This is now two different deployments, one for the authoring environment and one for the editing host.

1
2
3
4
5

# Deploy editing host
dotnet sitecore cloud editinghost deploy --environment-id ${edtEnvId} --upload

# Deploy authoring environment
dotnet sitecore cloud deployment create --environment-id ${envId} --upload

Perspective

Even though you are using the same repository, this might actually be beneficial. It is the authoring environment that takes the longest time to deploy and it can happen (at least for us) that you have changes to the components in the editing host without changes to the authoring environment. Now we can very fast deploy the updated editing host to allow editors to have the real preview and benefits of the updated components, without the need for recycling the authoring environment.