In this lesson, you’ll explore real-world use cases of managing environments using the data-ops tool. You’ll learn how to back up and sync models, migrate content, and maintain clean, consistent environments for efficient and reliable deployments.
Now that you’ve explored the data-ops tool and its capabilities, let’s apply it to some practical, use cases.In this scenario, you will learn how to:
Management API key with sufficient permissions to manage environments, content, and assets.
Code examples are provided to help you along the way. Replace any <placeholder> values with those that match your own project and environment settings.
The development team has just completed developing a new feature in the dev environment. It includes updates to the content model and three supporting content items. The feature has passed testing and is ready to move through the deployment pipeline: sync to staging from dev for final testing, then to production for release.
A new feature has been developed and tested in the dev environment. It includes updates to the content model as well as some test content items. Deploy the changes to staging for final testing before production release.To achieve this, you’ll use the following data-ops commands:
sync snapshot
sync diff
sync run
Create a snapshot of the dev environment to capture its current state for version control and review before syncing. The new feature introduced changes to content types, content type snippets, and taxonomies. Streamline the snapshot targeting just those entities, rather than capturing the entire content model.
Set up the dev sync snapshot command to include only contentTypes, contentTypeSnippets, and taxonomies. A folder will be created that includes the snapshot metadata files—review them to ensure their accuracy.
With the snapshot created, compare dev with staging using the sync diff command. This command shows the changes that would be applied if you were to synchronize the environments, highlighting additions, deletions, and updates across model metadata, such as content types, taxonomies, and snippets. Reviewing this diff ensures you only promote intentional changes and helps catch discrepancies before deploying to production.
To enable an interactive HTML report, set the advanced parameter to true and specify an outPath where the report will be saved locally. The visual diff report makes it easier to identify issues, understand structural changes, and share insights with both technical and non-technical stakeholders.
For this use case, you’ll include the source (dev) and target (staging) values, enable the visual diff, and set an output path. Your generated report should clearly highlight all changes related to the new feature.
After verifying the environment changes using the visual diff, sync dev to staging using the sync run command.
Since the new feature only affects contentTypes, contentTypeSnippets, and taxonomies, target just those entities using the entities parameter to keep the deployment focused and avoid unnecessary changes to production.
Execute the command and monitor the output closely. If everything runs smoothly, both dev and staging should be in sync. Check the content types, snippets, and taxonomies to verify that the new feature changes were applied correctly to staging.
Allow team members to access the staging environment to create test content items and provide feedback. Use their feedback to refine the content model. Once finalized, prepare 3 sample content items as a reference for content creators. These sample items will be migrated to the production environment later.
Once all reviews and approvals are complete, execute the sync diff command to compare staging with production. After reviewing the changes, use the sync run command to synchronize production as the target environment and staging as the source environment.
The new feature has been successfully deployed to production. To complete the rollout, you need to migrate the related content items from staging that support it. This ensures the feature works as expected.
After QA testing in staging, the team created sample content items earlier that demonstrate how to use the new feature effectively. Migrate these approved items from staging to production, so content creators can learn from these examples and create content for customers.
For this use case, you’ll use the migrate-content run command.
Identify the following parameters needed for the content migration command:
Environments IDs and Management API keys for the source and target environments.
The codenames of those three content items to migrate, such as item1, item2, and item3.
To get a content item’s codename, go to More actions > Codename.
Since only three content items need to be rolled out, run the migrate-content command without creating a snapshot. This focused migration command ensures only the necessary content is copied, keeping production aligned with the new feature.
Once the command is executed, progress updates, details of the migrated items, and any errors or warnings will display. Review the output to confirm that all expected content was successfully transferred.
Confirm that all three items exist in the production environment. If any taxonomies or snippets were updated within the items, ensure those changes have also been correctly migrated.
You‘ve successfully migrated content items from staging to production. All items have been reviewed and approved, marking the final step in rolling out the new feature.
Following the successful rollout of the new feature to production, the dev environment has become cluttered with experimental features and outdated content. Resetting the dev environment allows developers to start with a clean slate. For this use case, you’ll use:
Sign in with your Kontent.ai credentials or sign up for free to unlock the full lesson, track your progress, and access exclusive expert insights and tips!
Carlo Vinci, Samina Minda Hossain
10 minutes
setup.
More actions > Codename.