Example: Manage environments with data-ops

Practical data-ops use cases

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:

• Sync across environments to promote changes
• Migrate content items between environments
• Backup, clean, and restore an environment

Prerequisites

To follow along, you’ll need:

• Access to a terminal or command-line interface capable of executing data-ops commands.
• Data-ops tool setup.
• Three environments in your project: Dev, Staging, and Production.
• Environment IDs of Dev, Staging, and Production.
• 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.

Scenario

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.

Use case 1: Sync content model across environments

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

Step 1: Create a dev snapshot

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.

Step 2: Compare dev snapshot with staging

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.

Step 3: Sync dev to staging

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.

Step 4: Create and test sample content

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.

Step 5: Sync staging to production

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.

Result

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.

Use case 2: Migrate content to production environment

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.

Step 1: Identify what to migrate

Identify the following parameters needed for the content migration command:

• Environments IDs and Management API keys for the source and target environments.
• Language codename.
• 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.

Step 2: Run the content migration

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.

Step 3: Verify in production

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.

Result

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. 

Use case 3: Backup, clean, and restore