Installation patterns

This section provides patterns for deploying Semarchy xDM in real-life environments.

Pattern #1: Development, QA/UAT, and production on different sites

This pattern assumes that the development, Quality Assurance, User Acceptance Tests (QA/UAT), and production sites are located on different networks or sites.

For this pattern, the following three repositories are created:

  • A REPO_DEV Design repository for the development site. A DEV Development data location is attached to this repository. This location is used by the development team to test their work.

  • A REPO_QA Deployment repository for the QA site. A QA Production data location is attached to this repository. This location contains QA data and allows for limit values testing.

  • A REPO_PROD Deployment repository for the production site. A PROD Production data location is attached to this repository. Only closed and production-ready model editions can be deployed in this location. The real production data is here.

With this configuration:

  • The entire development phase is performed in the REPO_DEV repository, with closed and open model editions. Model editions are deployed to the DEV data location, for the developers' tests.

  • When the development phase is over, model editions are closed and exported to files from the REPO_DEV repository and imported in the REPO_QA repository. These closed model editions are deployed to the QA data location for testing.
    QA teams perform testing to ensure the model is bug-free and ready for production.

  • Once the user testing/QA process is finished, the closed model editions are exported from the REPO_QA to the REPO_PROD repository and then deployed to the PROD data location.

With this configuration, you need to deploy three instances of Semarchy xDM, one per repository. These three instances are located on three different networks with possibly different security, scalability and high availability requirements and settings.

Pattern #2: Development, QA/UAT and production on different sites

This pattern is similar to Pattern #1 but assumes that development and QA/UAT are co-located on one site, and production is located at a remote location.

For this pattern, two repositories are created:

  • A REPO_DEV Design repository for the development and QA site. A DEV Development data location and a QA Development data locations are attached to this repository.

  • A REPO_PROD Deployment repository for the production site. The PROD Production data location is attached to this repository.

With this configuration:

  • Models are developed in the REPO_DEV repository and tested by developers in the DEV data location.

  • When a milestone is reached, models editions are closed. These closed model editions are deployed to the QA data location for testing.

  • Once the QA phase is over, the closed model editions are exported to files from the REPO_DEV repository and imported in the REPO_PROD repository. From this repository, these closed model editions are deployed to the PROD data location.

With this configuration, you need to deploy two instances of Semarchy xDM, one per repository. These two instances are located on two different networks with possibly different security, scalability and high availability requirements and settings.

Pattern #3: Single repository and project

This pattern assumes that a single project is designed through a development/QA/Production lifecycle.

For this pattern:

  • A single Design repository is created.

  • Three data locations, DEV, QA and PROD are created:

    • DEV is a Development data location into which open model editions are deployed during the development phase.

    • QA is a Development data location into which the model editions closed by development are deployed for QA consumption. Possibly, open model editions can be deployed directly from development for immediate testing.

    • PROD is a Production data location.

In this pattern, a single repository contains the development, QA and production editions of the models. Model versioning allows freezing and delivering a model to the next stage (and next deployment location) as it moves along its lifecycle.

Patterns #1 and #2 are suitable for real enterprise environment. Pattern #3 is suitable for prototyping or evaluation environments.

Pattern #4: Single repository, multiple projects

This pattern is similar to Pattern #4 but assumes that several projects/models are managed in the same repository.

For this pattern:

  • A single design repository is created.

  • Three data locations are created per project: DEV1, QA1 and PROD1, then DEV2, QA2, PROD2, etc.

The organization is the same as in Pattern #3, but a set of data locations exists for each project managed in the single repository.

You can combine this pattern with Patterns #1 and #2 to manage multiple projects across multiple development, QA and production environments.