I’m a CTO. It’s a pretty rewarding job—especially if you like to wear many hats. You’re a technologist, a strategist, and occasionally the help people go to when turning a computer off and on just didn’t fix the problem.

The gig can get just a little stressful. Just a tad. Want to see your CTO turn white as a ghost? Tell them there’s been a failed deployment and the company’s site is down.

CTOs are so freaked out about the prospect of a failed deployment that they, and the smart DevOps people they hire, typically invest a fair amount of time and effort into “hardening” the deployment process.

Rule #1. No live coding on the production server!

The chance of something catching fire is just too great. Take this risk, and you’ll likely be writing something along these lines in an incident report:

“The site was down for 2 hours, with an estimated revenue loss of $6,000. Believe me, we were just as surprised as you were. The code actually looked pretty good.”

Now, I know what you’re thinking:

“This could never happen to us! We’ve got an extensive development pipeline. Independent development, QA, UAT, staging builds, etc. Code changes are thoroughly reviewed and tested before they get anywhere even remotely near production.” 🤓

Good for you. You’re following rule number 2:

Rule #2. Get serious about DevOps

Continuous integration. Continuous deployment. You’ve got code changes well and truly managed. Awkward incident report averted? Not quite. You see, it’s not just your code that changes over time. Assuming your solution also has data, then these, too, will evolve. Not only will you add new data over time, but the very structure of the data will change to meet new requirements.

If you’re using a headless CMS as part of your solution, then that, too, will be storing “data”—or, as it’s more typically referred to in the world of CMS, “content”. The structure of that content is defined in a content model. Adding and updating features on your site, app, digital product, etc., will likely require structural changes to your content model. The very same structure that production just so happens to be depending on right now. Change the wrong thing, and guess who’s writing another incident report?

“The site was down for 2 hours, with an estimated revenue loss of $6,000. Believe me, we were just as surprised as you were. Turns out the code expects a certain content structure. We removed an element in a content type to test an idea, and, well...ooops?”

You might be able to manage content model changes with feature flags, very defensive coding, and just not deleting bits of your content model that you no longer need. You might, but here’s the deal: at some point changes are going to be significant enough that things are going to break.

You set up multiple environments to manage updates to your code. Remember rule #1? No live coding on the production server. We need to take the same approach with our content model. This is exactly where Kontent.ai environments come in.

An environment in Kontent.ai is a complete copy of your content model (and, optionally, the actual content as well) within the same project. You can create them under Project Settings > Environments:

Just as code is organized into branches, a Kontent.ai environment can be created so that each build has its own version of the content model and content inventory.

Each Kontent.ai environment has everything you’ll need for your development pipeline builds. It comes with its own:

• API endpoints, so your build can get to the content and content model
• Webhooks that can be used to trigger builds in your development pipeline
• Preview URLs, so editors can preview changes for that specific build and Kontent.ai environment combination
• A whole bunch of other stuff like unique workflow and language settings

This affords all the isolation you’ll need to safely make content model changes and test them before moving them up to production. You don’t have to tell editors to ignore content model changes on production that are “work in progress” but not yet ready for prime time. You don’t have to worry about something accidentally going live—or for that matter—the entire site going down!

As for how to migrate your content model changes from one Kontent.ai environment to another, this can be done using the Kontent.ai CLI and Kontent.ai Management API.

We’ve been using Kontent.ai environments and migration scripts on our agency website to make, test, and deploy large changes to the underlying content model. Our team of content strategists and developers are happy to be out of production, and to leave that to the marketing folks creating content. Instead, the team can experiment in a safe Kontent.ai environment that’s connected to a separate non-production build. No incident report required 😄, though I imagine it would read:

“The development site went down. Whatevs.”

Environments are available in all Kontent.ai plans—even the free Developer one! Take the fear out of your deployments and start using them today.