Recommended Structure Of XDM Environments

Overview

This article explains how to operate XDM in separate DEV, TEST, and PROD environments and how configuration changes can be moved between them in a controlled and traceable way. It is intended for administrators, technical leads, and operations teams responsible for maintaining a stable and reliable XDM setup. The article covers the purpose of each environment, recommended permission models, and the use of YAML, Git, and Configuration as Code (CasC) to manage and promote changes. It does not provide detailed installation or CasC setup instructions. Its goal is to support a clear and testable change process, reduce production risks, prevent uncontrolled configuration changes, and ensure consistency across environments.

Using separate DEV, TEST and PROD Environments

Companies that use XDM should operate three separate environments:

  • Develop Environment (DEV)

  • Test Environment (TEST)

  • Production Environment (PROD)

Using separate environments helps to ensure that the main production environment remains stable and works correctly at all times.

  • DEV – design and implementation of new configurations and experiments

  • TEST – validation and acceptance of changes from DEV

  • PROD – business‑critical, day‑to‑day operations with approved configurations only

DEV Environment

On the DEV Instance new configurations will be created and/or changed for example:

  • DataShops and order forms

  • Workflows and Tasks

  • Modification rules and scripts

  • Application model and Environments

On the DEV environment, every user who creates or changes configurations or objects must have the required permissions. You are free to experiment here. Mistakes are allowed, as the DEV environment is not used productively.

TEST Environment

The TEST environment is used for acceptance and integration testing before changes are promoted to the Production environment.

New configurations and changes are validated on TEST before they are used in production. Configurations from DEV can be transferred to TEST by exporting and importing YAML files, or, ideally, by using Overview Configuration as Code (CasC). If you want to set up CasC first, refer to Setup CasC documentation before continuing.

New XDM versions will be tested here first, so any issues will not affect the PROD or DEV environments.

On TEST, permissions should be restricted as follows:

  • Users may only read and execute objects (for example Tasks, Workflows, or starting DataShops).

  • Users must not change configurations directly through the UI.

  • If a configuration change is required, it should be implemented in the DEV environment first and then re‑imported into TEST.

  • For configuration changes that are transferred to TEST, a four‑eyes principle should be applied, for example by reviewing the changes in the Git repository before they are imported.

PROD Environment

The PROD environment is the main production instance and is used for business‑critical, day‑to‑day operations.

On PROD, XDM is used productively:

  • Productive DataShops for business users

  • Regular Workflows for providing test data

  • Acceptance‑relevant test and regression runs

Only approved configurations should run on PROD, and access to PROD must be strictly limited:

  • Configuration changes must not be made directly in the UI.

  • New or modified objects are deployed exclusively by export/import or by using Configuration as Code (CasC) from the Git repository.

  • The company‑wide change‑management process (for example CAB approvals, change tickets) must be followed.

This separation keeps responsibilities clear: development happens on DEV, acceptance and testing on TEST, and stable operation on PROD.

Technical Foundations: Export/Import, YAML and Configuration as Code

Configuration is moved between environments by exporting and importing YAML files. It is recommended to store these YAML files in a Git repository for version control and to use Configuration as Code (CasC) to automatically import them into the target environments.

On DEV:

  • Export objects through the UI, ideally as a ZIP file that contains files for every object.

  • Unzip the exported files before using them.

  • Commit the exported YAML files to a Git repository as Configuration as Code.

  • Link commits to change or requirement tickets (for example in Jira) so that requirements and changes remain traceable.

On TEST and PROD:

  • Configure XDM to regularly read from the Git repository and automatically import new or changed objects (CasC job).

  • Use a dedicated branch for each environment (for example TEST and PROD).

  • Avoid manual changes in TEST and PROD so that the actual configuration state always matches the state in Git.

In a three-environment setup, the TEST branch is filled after changes have been developed and tested on DEV. The relevant XDM objects are exported from DEV, copied into the Git repository, reviewed, and committed to the TEST branch, for example TEST. After the configuration has been imported and validated on TEST, the tested changes are promoted to PROD by merging the TEST branch into the PROD branch, for example from TEST into PROD. XDM-PROD then imports the merged changes from the PROD branch.

With this approach, all changes to the XDM configuration are traceable, versioned, and can be reviewed before they are applied.

Shared Database connections across Environments

Ideally, all three environments (DEV, TEST and PROD) are connected to the same business‑relevant databases or backend systems:

  • On DEV, tasks, workflows, DataShops and Modification rules can be developed against realistic structures and data.

  • On TEST, the same connections and data models are used that will later be active on PROD.

  • This avoids surprises where a configuration works on DEV or TEST but fails on PROD because a connection, schema or table structure is different.

In real work installations this often is not allowed. However, the closer all three environments are and the more similar setups, the fewer problems will reach the production installation.

It is important to model the required database connections and environments centrally in XDM and to keep them consistent across all instances.

Scenario 1: Developing and rolling out new configurations

This scenario describes the typical lifecycle of new configurations, for example a new DataShop or Workflow.

  1. Development on DEV

    • New or changed DataShops, Workflows, Tasks, Modification rules, Application models and similar objects are created and tested on DEV.

    • On DEV, all involved team members are allowed to create and change configurations.

  2. Export to Git

    • The finished or test‑ready objects are exported from DEV as YAML or ZIP files.

    • These files are committed to a central Git repository as Configuration as Code.

    • A review in the Git system (four‑eyes principle) ensures that all changes are checked before they are used in other environments.

  3. Import to TEST using CasC

    • The XDM TEST environment reads the defined Git branch (for example xdm-test) at fixed intervals and imports new or changed objects using CasC.

    • Perform technical and business acceptance on TEST.

  4. Corrections if needed

    • If errors or functional deviations are found:

      • Apply the required changes on DEV.

      • Export the updated configuration and commit it to Git again.

      • Let TEST re‑import the changes via CasC.

    • This DEV → Git → TEST cycle is repeated until the configuration is stable and accepted.

  5. Rollout to PROD

    • Once the configuration is approved on TEST, the tested branch (for example xdm-test) is merged into the PROD branch (for example xdm-prod).

    • The PROD environment reads this branch and imports the changes automatically using CasC.

    • No manual changes are made through the UI on PROD so that the actual configuration always matches the state in Git.

All three environments should run the same XDM version. When importing, XDM validates, among other things, the version of the exported configuration. Newer features may cause import problems on older instances.

flowchart LR subgraph DEV["Development on DEV"] CHANGE["Create, change, and test configurations"] EXPORT["Export configuration\nYAML or ZIP"] CHANGE --> EXPORT end subgraph GIT["Git / CasC"] COMMIT["Commit files to Git"] REVIEW["Review changes"] BRANCH["CasC uses defined branch"] COMMIT --> REVIEW --> BRANCH end subgraph TEST["TEST"] IMPORT["Import via CasC"] TESTS["Run technical and business tests"] DECISION{"Everything correct?"} REWORK["No: fix on DEV\nand repeat"] IMPORT --> TESTS --> DECISION DECISION -.-> REWORK end subgraph PROD["Rollout to PROD"] MERGE["Merge to PROD branch"] PRODIMPORT["PROD imports via CasC"] STATE["PROD matches Git state"] MERGE --> PRODIMPORT --> STATE end EXPORT --> COMMIT BRANCH --> IMPORT DECISION -->|Yes| MERGE style GIT fill:#E8F1FF,stroke:#2F6FDB,stroke-width:2px,color:#000000 style COMMIT fill:#F4F8FF,stroke:#2F6FDB,color:#000000 style REVIEW fill:#F4F8FF,stroke:#2F6FDB,color:#000000 style BRANCH fill:#F4F8FF,stroke:#2F6FDB,color:#000000 style REWORK fill:#FFF4E5,stroke:#D97706,color:#000000

Scenario 2: Testing new XDM versions with your own configuration

To introduce new XDM versions safely, a staged rollout across the environments is recommended.

  1. Update TEST first TEST will be used first to install new XDM version updates because:

    • TEST contains the most stable and acceptance-relevant configuration next to PROD.

    • If there are problems with a new XDM version, then neither PROD nor the development on DEV are affected directly.

    • This ensures that there is never a newer version on DEV than in the other environments, so there are no problems where an export from DEV cannot be imported into TEST or PROD because of mismatching features.

    • Update the TEST instance first to the new XDM version.

    • Import the existing configuration from Git using CasC as usual.

    • Then test typical and critical processes (Workflows, DataShops, masking, integrations).

  2. Analyze and fix issues

    • If there are problems with the configuration, they can be fixed on DEV and then deployed to TEST.

    • If there are problems with XDM itself, waiting for a bugfix will not block PROD or DEV, and fix versions can be tested on TEST again.

    • Configuration changes are applied on DEV and then promoted to TEST via Git and CasC until all tests are successful.

  3. Update DEV and PROD

    • When all important use cases work on TEST, update DEV and PROD to the new XDM version.

    • On DEV, new features of the version can then be used for further development.

    • PROD is updated last, once it is clear that both version and configuration are stable.

  4. Update frequency and hotfixes

    • New XDM versions should typically be installed within about three months to benefit from bug fixes, security updates and new functionality in a timely manner.

    • Using XDM versions older than 3 months is possible, but the older the version gets, the harder it will be to fix any problems and the greater the risk of migration to a current version.

    • For urgent issues, a single object (for example an adjusted Task or Workflow) can be provided quickly via export/import or CasC as soon as a fix from the vendor is available.

flowchart LR subgraph TEST["TEST"] TESTUPDATE["Update TEST first"] TESTS["Test critical processes"] TESTUPDATE --> TESTS end subgraph ANALYSIS["Analysis"] CHECK{"Problems found?"} end subgraph DEV["DEV"] FIX["Fix on DEV"] UPDATEDEV["Update DEV"] end subgraph GIT["Git / CasC"] DEPLOY["Deploy fix to TEST"] end subgraph PROD["PROD"] UPDATEPROD["Update PROD last"] end TESTS --> CHECK CHECK -->|Yes| FIX FIX --> DEPLOY DEPLOY --> TESTS CHECK -->|No| UPDATEDEV UPDATEDEV --> UPDATEPROD style GIT fill:#E8F4FF,stroke:#4A90E2,stroke-width:2px; style ANALYSIS fill:#FFF3CD,stroke:#D6A800,stroke-width:2px; style TESTUPDATE fill:#D1FAE5,stroke:#059669,stroke-width:3px,color:#000000;