Sitecore Symposium - The complete development lifecycle - Part 1

The Sitecore Symposium is the greatest and biggest Sitecore event of the year. This time, it was held in Chicago at McCormick Place. With almost 2.500 attendees it's by far the biggest event for me this year. Therefore, I was excited to be invited to do a presentation about the Content Hub development lifecycle at the Symposium. This way I could share my lessons learned from working with Content Hub over the last two years.

In all fairness, I didn't know what to expect for the number of attendees that would be interested in this topic. A week before the Symposium, I was contacted that the registration for my talk was starting to fill up fast and if I was interested in giving the presentation twice. Yeah, why not? So, I did. How cool is that, going to your first Symposium and doing two talks.

But enough chit-chat, let's discuss the presentation, for those of you that couldn't attend the presentation. Let's take a look at the agenda.

It starts with taking a dive into the development lifecycle. In this part, I talk about the development process and that at Macaw we really love working in an Agile process. With an Agile process, you will work for a short period of time (2 - 3 weeks) on the project. At the end of the period, the team will deploy the results of that period. Thus delivering business value for the customer. What I've learned over time, is that customers aren't always able to tell upfront what they want. With these short iterations, a customer is able to see what you've done, and therefore better sees the impact. This way, the customer is able to adjust the way the project is going much faster.

Let's continue to the next slide, the Habitat. What could a possible Content Hub habitat look like? Who might work on such a project, etc. If you take a look at the image below, you might notice there are two types of environments: sandbox and instances. The Sandbox is a cheap way of doing Content Hub development, although the performance isn't the same as when running an actual instance, keep this in mind! The instance is the actual Content Hub, which is created and fully supported by Sitecore.

What you can see in this image is that the Content Hub configuration manually flows from Dev environment(s) to multiple instances like Test, Acceptance (also known as QA) and Production. This is what a Corporate and Enterprise habitat could look like. Sometimes, it happens that you're working on a smaller Content Hub project and the customer only has one Content Hub instance. You then might use another sandbox for QA. However, I would always push the customer for having at least two Content Hub instances. A sandbox is not a proper substitute for an instance. But with another sandbox, you can at least test if the changes that you've made on Dev work. 

As you might have noticed on the slide, that is actually one person standing in the middle to maintain all the imports and exports. In the beginning, this will be fairly easy and straightforward. But as you might guess, his position starts to become difficult quite fast as the team progresses. So what other challenges do we see?

At this point during the talk, I'll explain the different challenges that I found during my experience working with Content Hub. Trying to maintain all changes across the environments. In the next slides, I'm going over each challenge and how to resolve it.

So the first challenge is getting the configuration out of Content Hub. By default, the Content Hub supports exporting the configuration via the UI. You can do this via the Import / Export package option in the Management section of the Content Hub. If you press export in the UI, it will create an asynchronous job for you in the background to create a ZIP package with the configuration. This process takes time, you need to wait for and then manually download the package. Would it not be easier to just run a command and wait for the process to be completed in the background while you're working? With the use of Content Hub CLI, you can do this.

So how can you create an export? Well first, you need to install it of course. You can do this with the following command:

Windows

choco install sitecore.ch.cli --source https://slpartners.myget.org/F/m-public/api/v2

Linux

brew tap sitecore/content-hub
brew install ch-cli

Note: Requires Homebrew.

After installation, you can start working with the CLI. The first thing you'll need is an endpoint aka a Content Hub instance/sandbox to work with. You can add an endpoint with the following command:

ch-cli endpoint add --name <name> --url <https://your.content.hub.url/> --client-id <OAuth client ID> --client-secret <OAuth client secret>

Change the text between the bracks <> with your settings. Once you've successfully created an endpoint you can send a command to your instance. For example, trigger an export with this command:

ch-cli system export --type AutomationTemplates|[etc] --wait --order-id

--type, here you can specify which types you would to download. Remark: Currently the CLI only supports exporting one type per command. Therefore, you can't export the whole configuration at once. I hope this will be resolved in the future. Actually, you can export multiple commands at once. Just add more --type to the command line.

--type AutomationTemplates --type EntityDefinitions --type ExportProfiles --type MediaProcessing --type OptionLists --type Policies --type PortalPages --type RenditionLinks --type Scripts --type Settings --type StateFlows --type Taxonomies --type Transformations --type Triggers

--wait, waits for the completion of the task

--order-id, returns the order ID

With the order id returned, you could easily create an extension to download the ZIP package from the Content Hub. Now that we're able to automatically export a config, let's move on to the next challenge.

Stay tuned. Part 2 of the blog post will come online next week.

Happy codin'.