A publisher is an environment that can make its versions available for other environments.

A subscriber is an environment that will contact the publisher in order know if new versions are available, download the new versions and integrate the new versions.

The versioning and distribution process works as follows:

The starting point of the publishing process is the creation of a version. When the content of the working version is considered as “final” and “stable”, a version can be produced. The newly created version does not trigger the publishing process, but it is a prerequisite.

A version which has been created is not considered as “published”. In order to publish it, and thus make it available for all subscribers, it needs to be exported. The export can issue multiple files:

• The exported model, either in compressed or in xml format
• The rich media gallery, in compressed format
• The theme files (meaning: the layout XML files as well as the theme folders)
  Tip: Although the versions are available in the repository, the exported versions are a valuable backup. Do not delete the exported versions recklessly.

Once a version has been created and published, it can be downloaded by all subscribers. In order to do that, a subscriber will first “poll” the publisher in order to know which versions are available, and will be able to download one or multiple versions that it is interested in.

One the new version has been downloaded, it can be imported. The import process allows detecting conflicts, and can create log files if needed. The import process will also enable you to import the rich media gallery or the themes.

Once the information has been integrated in the working section, the subscriber can create a new version. Before creating the new version, make sure that

• The conflicts have been correctly managed
• The rich media gallery has been correctly integrated
• The updated model(s) and theme(s) have been thoroughly tested
  information: At this point in time, the version is completely distributed and deployed in the subscriber’s environment.

The Designer offers 2 distribution modes: manual or automatic. In a Manual Distribution mode, all steps are triggered manually. The manual distribution mode enables you to control all aspects of the distribution process:

• Decide precisely when you want to export (publish) a version
• Decide precisely which version to download, and at what time
• Decide precisely when to import, what to do when conflicts arise, and how to manage them
• Decide precisely which projects and objects are a part of the new version to be created
• Decide precisely when this new version will be applicable

The Automatic Distribution mode enables you to automate all these aspects.

In order to have a better insight into these 2 modes, take again a look at the typical architecture. In this setup, some machines will act as a publisher only, others will alternatively act as

a publisher or a subscriber and yet others will act as a subscriber only:

designed to mirror two systems (the publisher and the subscriber). The information (version name and fix name) contained in the imported data file is used to automate the creation of the version in the destination environment. Beware that if the working fix or working version that is used to import the data file contains additional objects, then conflicts will be resolved first during the import and then the versioning process will be triggered on all workspaces.

Moreover, in this typical architecture, the 2 distribution modes will co-exist, as shown in the following image:

In the left part, the manual distribution mode will be used, and this for the following reasons:

• Conflicts can arise when integrating the results from 3 development servers on the integration server
• The versions received from the 3 development servers can have identical names or conflicting application dates
• The result from the development servers has to be tested and modified before being able to produce a “real” version

  Definition: A conflict is a situation where, during the import of an object X issued by environment A into environment B, an object Y having the same identifier (workspace/class/name) already exists in the working version of environment B.

In other words, a conflict arises whenever an object to be imported is already present in the working version (or working fix).

When conflicts arise, they have to be managed. There are 2 policies that can be applied in order to resolve conflicts:

In case of a conflict during the import of an object in the working section, the “Keep local” policy will reject the to-be-imported object and keep the object already in the working version.

The “Override” policy will reject the object in the working version and update it with the information coming from the to-be-imported version.

In the context of versioning and distribution, 3 steps are available form the “Deploy” section of the Dashboard:

This step allows you to select all the projects and/or individual objects in order to include them into a version, and allows you to create the version itself.

Configure the settings for the publisher

This step allows you to publish versions, after they have been created.

• Manage Subscription

  This step allows you to define all the parameters of the subscription, in order to automate the download, import and integration of newly arrived versions.

This step allows you to manage all versions on the subscriber, in order to download, import or integrate them.

This step allows you to look at the content of each published version in comparison with the previous version. It also allows you to delete versions which are no longer applicable.