Managing Model and Data Editions |
Previous
|
|
Next
|
Managing Repositories |
|
Managing the Platform |
Managing Model and Data Editions
This chapter discusses administration considerations related to Model and Data Editions management.
Understanding Model and Data Editions
Semarchy Convergence for MDM manages two flows of changes:
-
Model Changes are handled using
Model Editions. This version control mechanism allows you to freeze versions of a model (called Model Editions) then deploy them for data loading and integration processing in a
Data Location.
-
Data Changes are handled using
Data Editions. This data version control mechanism allows you to freeze versions of the data (called Data Editions) at any point of time.
A data edition is always based on a given model edition. This means that this data edition contains data organized according to the model structure in the given model edition, and that golden data in this data edition is processed and certified according to the rules of the model in the given model edition.
These two version control mechanisms can be used simultaneously and in parallel threads.
Version Numbers
Model and data editions are identified by a version number. This version number format is
<branch>.<edition>
. The branch and model numbers start at zero and are automatically incremented as you create new branches or editions.
For example, the first model edition in the first branch has the version
[0.0]
. The fourth edition of the CustomerAndFinancialMDM model in the second branch is named
CustomerAndFinancialMDM [1.3].
Model Editions
A
Model Edition reflects the state of the model at a given point in time.
Actions on Model Editions
Model Editions support the following actions:
-
Creating a New Model creates the first edition of the model.
-
Closing and Creating a New Edition of the model freezes the model edition in its current state, and opens a new edition of the model for modification.
-
Branching, to maintain several parallel branches of the model. You create a branch based on an existing closed model edition when you want to fork the project from this edition, or create a maintenance branch.
-
Deployment, to install a model edition in a data location. You can deploy several editions of the same model within the same data location.
-
Update, to re-deploy an open model edition on top of a previous deployed edition. This update process allows to iteratively deploy a model and its integration process, then test it without creating successive editions of this model. This update option is only possible on development data locations.
-
Export and
Import model editions, to transfer them between repositories.
Refer to the the following chapters for more information about model editions management tasks:
-
"Models Management" chapter in the
"Semarchy Convergence for MDM Developer’s Guide".
-
"Deployment" chapter in the
"Semarchy Convergence for MDM Developer’s Guide".
Model Editions Lifecycle
The model edition lifecycle is described below.
- The project manager
creates a new model and the first model edition.
- Developers edit the model metadata. They perform their logical modeling and integration process design activities.
- When the developers reach a level of completion in the project, they
deploy the model edition for testing, and afterwards
update the model edition while pursuing their developments and tests. Such actions are typically performed in a development data location. Sample data can be submitted to the data location for integration in the hub.
- When the first project milestone is reached, the project manager:
-
Closes and create a new model edition.
-
Deploys the closed model edition or
exports the model edition for deployment on a remote repository.
- The project can proceed to the next iteration (go to step 2).
- When needed, the project manager
creates a new branch starting from a closed edition. This may be needed for example when a feature or fix needs to be backported to a close edition without taking all the changes done on later editions.
The following points should be taken into account when managing the model editions lifecycle:
-
No Model Edition Deletion: It is not possible to delete old model editions. The entire history of the project is always preserved.
-
Update in Design-Time Only: Although update is a useful feature in development for updating quickly a model edition, it is not recommended to perform updates on data location that host production data, and it is not recommended to use development data locations for production. The best practice is to have
Production Data Locations that only allow deploying closed model edition for production data.
-
Import/Export for Remote Deployment: It is possible to export and import model from both deployment and development repositories. Importing a model edition is possible in a Deployment Repository if this edition is closed.
-
Avoid Skipping Editions: When importing successive model editions, it is not recommended to skip intermediate editions, as it is not possible import them at a later time. For example, if importing edition 0.1 of a model, then importing edition 0.4, the intermediate editions – 0.2 and 0.3 – can longer be imported in this repository.
Data Editions
A
Data Edition reflects the state of the data in a data location at a given point in time.
Actions on Data Editions
Data Editions support the following actions:
-
Creating a Root Branch creates the first edition of the data, based on a given deployed model edition.
-
Closing and Creating a New Edition of the data freezes the edition in its current state, and opens a new edition of the data for modification, on the same or a different deployed model edition.
-
Switching Model Edition changes the deployed model edition supporting a given data edition without closing the data edition.
- Data Editions can be moved to a
Maintenance status. This status prevents new external loads to be submitted in this data edition. This mode can be used before closing a data edition, or when switching it to a different deployed model edition.
Refer to the the following chapters and guides for more information on data editions managements:
-
"Models Management" chapter in the
"Semarchy Convergence for MDM Developer’s Guide".
-
"Deployment" chapter in the
"Semarchy Convergence for MDM Developer’s Guide".
Data Editions Lifecycle
A typical Data Edition lifecycle (in the context of a Data Location) is described below.
- The administrator
creates the data location based on a given model
- The project manager
installs a first model edition (as described in the model editions lifecycle)
- The administrator
creates a root branch and a first data edition. Integration batches now target this data edition.
- The administrator manages data editions:
- When there is a data milestone, the administrator
closes and opens a new data edition, based on the same deployed model edition.
- When a new model edition is
deployed by the project manager (as described in the model editions lifecycle), The administrator
closes and opens a new data edition, based on this newly deployed model edition or
switches the model edition of the same data edition.
Important: In production, after deploying a
new model edition, remember to create a
new data edition based on this model edition or
switch the existing data edition to the new model edition. Otherwise, the data edition in place still uses its old model edition. In development environments, when you use the update capability, the existing model edition is
overwritten, and as a consequence, the open data edition automatically benefits from the deployed updates.
Considerations for Data Editions Management
The following points should be taken into account when managing the data editions lifecycle:
-
Closed Data Edition are Read-only: When closing a data edition, make sure that no further changes are required on the data. It is better to move first the data edition to a
Maintenance state, as this state can be reverted.
-
No Data Edition Deletion: It is not possible to delete old data editions. The entire history of the hub is always preserved.
Defining the Version Control Strategy
The model and data edition feature is a framework supporting the organization of your MDM project.
It is important to perform version control planning according to your needs. The following questions should help this planning exercise:
- When will model editions be created? By who?
- When (at which frequency) will data editions be created? By who? What are the data milestones?
For example, you may decide as part of the version control plan that:
- For the
Customer hub project:
- An updated version of the
Customer hub is scheduled every 6 month for the next 2 years, and model editions must be created when these milestones are reached.
- At every milestone, a maintenance branch must be created to maintain the released version.
- The data in the
Customer hub can be version controlled once a year, and a yearly data edition is sufficient.
- For the
Product hub project:
- The data in
Product hub needs to be version controlled every quarter when the product catalog is released to the public, regardless of the project’s milestones.