Deploying changes to a new environment can be a nerve-wracking experience if there are questions about environmental differences or whether all related items have been accounted for. Fortunately, automating this process removes many of those questions early on, resulting in a more dependable environment and fewer headaches for developers.
Corey HamiltonPublished on Feb 18, 2020
To make this experience easier, the Kontent team has created a Command Line Interface (CLI) framework for migrating content updates to different environments. This framework can be combined with your favorite continuous integration tool to deploy changes as part of your automated deployment process. It leverages the latest improvements to our Management API, which added the ability to programmatically update content types and associated content items.
One of the most common use cases we hear from developers has to do with changes to an existing content type. Not only does the content type need to be updated and deployed to a testing environment, but the content items associated with it often need to be updated to fit the new structure as well.
Recently, we ran into this challenge on our own kontent.ai website. When we first built the website, we created a content type to display information for each of our partners. After launching the new website, we began to get feedback that several partners wanted to have all of their regional offices listed on their profile page—but we had only built the content type to account for a single location. To handle this change, we took the following steps to update our content type and partner data, and then deploy those changes to our testing environment to ensure we weren’t going to break anything on the production website.
- We set up our testing environment to utilize the CLI, according to the CLI Documentation.
- We created a new Address content type so that each partner address was saved as its own content item.
- We updated our partner content type to support multiple linked items of the new Address content type.
- Next, we pulled the list of content items that used the Partner content type, and took the data from the original Address field to create new content items (using the new Address content type).
- Using that same list of Partner content, we updated each item to link to the appropriate Address content items for that partner.
- Then, we updated our application code to retrieve address information from the new linked address items.
- We ran the migration scripts to deploy the new content type, associated content items, and application code to the testing environment.
- Once everything had been thoroughly tested, we removed the old address fields from the partner content type.
Of course, we don’t expect you to jump right into a live project and try this out for the first time. That’s why we’ve also created a CLI Migrations Boilerplate to provide you with examples to get your feet wet before using it on a real project.
Once you’ve given this a try, keep an eye out for future improvements to the developer experience with Kontent. We’re working on several exciting new features to further advance the code-first approach to content management while also making it easier to deploy to multiple environments. Lastly, we want to make sure we’re meeting all your development needs, so please reach out if there are other use cases you need help addressing.