How to support CI/CD with Content Hub?

Content Hub enthousiast Logo


I've developed a lot of solutions in the past decade and have seen a lot of changes come and go with software development. But one of the best things I've seen is the CI/CD (continuous integration and continuous delivery) process. It not only highly increases the speed of development but more importantly, we're as developers also able to faster increase the value for our clients. And in the end, that's what our work is all about.

When adopting the Content Hub as a new platform, I was having trouble incorporating the Content Hub into this way of work. Where they are a lot of integration components within Azure DevOps for the Azure platform, there were none for the Content Hub or so I thought.

Last week during the Sitecore Content Hub DAM Mock Implementation: Enterprise training, the instructor told us briefly about the Command Line Interface (CLI) that Sitecore has introduced. 

Command Line Interface (CLI)
A command-line interface processes commands to a computer program in the form of lines of text. The program which handles the interface is called a command-line interpreter or command-line processor.

The CLI is used for communicating with Sitecore Content Hub™ instances through the REST API using the C# Web SDK.
* copied from Sitecore docs

So what about the CLI of Sitecore Content Hub? Well, let first start with the versions it supports. At the moment, it only supports version 3.4 and above, I don't know if it will ever support the older version. If you need that, please contact Sitecore support. Let's continue and dive into the interesting part.

What can we do with the CLI?
  • Audit commands allow some basic querying options to retrieve and/or download audit logs from specific sources and over a specific time span. Also, allows an interactive mode where the current audit logs are spooled to the console as new audit entries are generated on the server.
  • Jobs command allows the user to monitor jobs in a Content Hub server, by querying for a job's status, viewing a job's reports, showing jobs statistics and listing all jobs.
  • Orders command allows the user to manage the orders on a Content Hub server, by fetching an order, querying an orders' status, deleting and order and listing all orders.
  • Queues command allows the user to monitor the various queues in a Content Hub server.
  • System commands allow the user to perform operations like package export/import.
  • Facilitates editing, compilation and publishing scripts. This is a PREVIEW command.    
* copied from CLI documentation

The command that we will focus on today is the System commands. This command will allow us to perform operations like package export and import. 

Why is that important? 
It will enable us to use our CI/CD way of work within Azure DevOps. The way this works is as follows:
  1. First, ensure that your development is equal to the production configuration
  2. Make the changes that are needed within the Content Hub. Keep the changes small, this will not only speed up the verification process but also make it reduce the risk to deploy the new functionality
  3. Use the CLI to export the configuration, including the changes, of your development
  4. Store the exported configuration in your code repository
  5. Create the PR to verify it and start testing the changes
  6. After approval, trigger the deployment to the next environment.
  7. Last but not least, check the changes
  8. Repeat from step 1.
CI/CD pipeline

* Image copyright by anchore

How can we export the Content Hub configuration?
As mentioned earlier we would need to use the system command to get export/import the configuration. When running the CLI you can always add --help to get more information about the command itself. When we run this command, you'll get the information below. Here we can see that the system command can be combined with either export or import. 

ch-cli system --help

For now, we are going to use the export command. We would like to extract our existing configuration from our Content Hub instance. So let's change the command: ch-cli system export --help. This will give us information about the export command. As you can see in the image below, the export requires one or more types to be specified with the export command. Don't forget to add this, because otherwise, you'll just get an error stating that the Option '--type' is required.

ch-cli system export --help

By default, the CLI will trigger an export request within the Content Hub. You can check the Downloads page within Content Hub to see your request. Since we strive for an automated process, we need a way to easily download the package when it comes available. Luckily for us, Sitecore has added the --out option for this. This allows us to specify a full filename where we can store our package. When we combine all this information together we get the following export command:
ch-cli system export --type AutomationTemplates EntityDefinitions ExportProfiles MediaProcessing OptionLists Policies PortalPages Rendition Links Scripts Settings StateFlows Taxonomies Transformations Triggers --out D:\export_all_config.zip

In the example above, we've combined all types into one go. If you do need them all, just remove the ones you're not interested in. Keep in mind that every type requires a space. The help doesn't mention this. Ok, now we've the export, how about importing this? Just keep on reading.

How can we import the Content Hub configuration?
Importing the configuration changes into a Content Hub instance isn't that different from doing an export. Let's execute the import help command to see the information of the import command. Execute the following text: ch-cli system import --help. It will return us with the information in the image below.

ch-cli system import --help

As you can see, this command also requires a property to be set. This is the --source property, this needs to point to the package we exported earlier. We also have the wait option (--wait) here as well. When we add this option to the command the system will not only trigger the import process but also starts it asap and follow it. When updating an environment it's my opinion that you should use this option. Otherwise, you will lose control over the import process and need to manually check if the import process has finished or not.

If you forget to add the wait option, no worries the CLI has got your back. When executing the command, it will output the job id that you can use to query the status via the CLI. You can also check the Backend processes page within the Content Hub.

ch-cli system import --source D:\test_all.zip

More on the CLI at the next blog post!