Import replication data

This topic describes how to import replication data that you have exported from another server, and how replication import is managed.

Import replication data

To import data to a target server, first export the data from your replication (source) server. For details, see Export replication data.

To import replication data:

  1. Navigate to Management > Applications.

  2. From the Replication menu, select Import. The Import Replication dialog box opens.

  3. Select a zip file containing the data to import.

  4. Specify the following import options:

    Option Description
    Import strategy

    Select the strategy for importing objects:

    • Name and ID-based. The system identifies imported objects by their ID and then name.
    • ID-based. The system identifies imported objects by their IDs.

      Note: If the server contains objects with matching names but different IDs, the import fails.

    For details, see Object import strategies.

    Properties merge strategy

    Select the strategy for merging properties during import:

    • Override (default). Replaces target server data with data from an import file.
    • Merge without conflicts. Merges properties from source and target servers. If the system detects conflicting changes to properties, the import fails.
    • Merge with replication priority. Merges properties from source and target servers. If the system detects conflicting changes to properties, target server data is replaced with replication (source) data.
    • Merge with server priority. Merges properties from source and target servers. If the system detects conflicting changes to properties, target server data overrides replication (source) data.

    For details, see Replication merge strategies.

    Plugins import strategy

    Select the strategy for importing plugins and plugin steps.

    • Upgrade all plugins (default). Upgrades all imported plugins to the latest versions.

    • Fail import for old Groovy version. Imports only the latest plugin versions.

    • Import ignoring old Groovy version. Imports plugins as is.

    For details, see Plugins import strategies.

    Disable auto-import Leave this option selected to disable automatic import for component versions. For details, see Import component versions.
    Override resource mapping Select this option to import resource mapping for global and application environments and to override the existing resource mapping.
    Ignore missing plugins

    Select this option to import processes even if they use plugins that are not available on either the replication (source) or target servers.

    After the import, the system displays a missing plugin warning instead of the properties for relevant steps.

    If the process step properties associated with missing plugins are encrypted, and if Deployment Automation can decrypt them, they are imported as secure. Otherwise, the system labels the properties as not secure.

    Note: After the import, load the latest versions of missing plugins to Deployment Automation. To correctly resolve properties in plugin steps, we recommend that you first import a plugin of the same version as in your source data. Use replication to import. Then load the latest plugin version to automatically upgrade plugin steps. For details, see Load and upgrade plugins.

  5. Choose how to proceed:

    • To import the replication data file as is, click Import.

    • To change the application and environment selections, click Next.

  6. If you selected Next in the earlier step:

    1. Select the applications that you want to import, and click Next.
    2. Select the environments that you want to import, and click Import.

The replication data is populated on the server as defined in the import options.

Back to top

Replication import behavior

The following table explains how the replication import is processed for different imported objects.

Item Description
Environments Exported environments are automatically selected for import. You can clear the selection in the import details if needed.

The system creates an environment on the target server if an environment with the same name doesn't exist.

For every imported environment, the associated set of resources and resource groups is also imported to the target server based on resource and resource group IDs.

If you select the Override resource mapping option during the import, a list of resources and resource groups is recreated for the existing environment.
Component Templates Component templates are fully imported to the target server.
Components Components are fully imported to the target server, including component versions contained in the data file.

If the component is deleted on the target server but exists in the data file, the system recreates the component on the target server.

Old component versions are not removed, but any new versions are imported to the component. You can import both full and incremental versions.
Global Processes Global processes are fully imported to the target server.
Applications Exported applications are automatically selected for import. You can clear selection in the import details if needed.

Applications are fully imported to the target server.

Environments are matched based on environment names rather than IDs.

Component mapping is performed based on the existing resource set. If some resources are missing, the system omits them during the component mapping import.

Application snapshots are fully imported, including associated component versions, application processes, component processes, properties, and other objects. During import, the snapshots are automatically linked to the imported versions of the corresponding objects in a target environment.
Resources Resources are fully imported to the target server.

If some resources are dependent on the environment that is excluded from the import, those resources are not imported.
Resource Groups Resource group meta information is fully imported to the target server.
Agent Pools Only basic meta information related to agent pools is imported to the target server.
Plugins During import, all plugins with the same version as those in the data file are overridden on the target server. Plugins added on the target server are not deleted during import.
Statuses The same rules apply as for the import of Resources.
Notification Schemes The same rules apply as for the import of Resources.
Resource Roles The same rules apply as for the import of Resources.
Security Roles The same rules apply as for the import of Resources.
Pipelines The same rules apply as for the import of Resources.

If one of the pipeline environments is excluded from the import, the pipeline is not imported.
Versioned Objects Versioned objects, such as property sheets and processes, are imported according to the merge technique described in the next section Versioned objects import. According to this technique, new versions are added to the target server.

Caution: The following rule applies to environments, component templates, components, global processes, applications, resources, pipelines, resource and security roles, statuses, and notification schemes:

If an object with the same name already exists, and its ID is different from the ID of the imported object, the system displays an error and cancels the import. If the IDs match:

  • The parameters of a target component, application, or resource are overridden based on the replication (source) data.
  • A new version of a component template or global process is created based on the replication (source) data.

Back to top

Versioned objects import

Versioned objects, such as property sheets and processes, are imported according to the merge technique that creates new versions on the target server.

Example: The following example explains what happens if the Versioned objects option is set to All:

  1. Assume there are 2 versions of a property sheet on the source (replication) server: Source 1, 2.
  2. The replication procedure recreates these versions on the target server: Target 1, 2.

  3. After this, a release engineer makes changes on the target server: Target 1, 2, 3*.

  4. Another release engineer makes changes on the source server: Source 1, 2, 3.

  5. Result: During replication, all versions that were added on the source server since the last import are imported as new versions: Source 1, 2, 3*, 4 (3).

    If there is a snapshot referring to version 3 on the source server, it refers to version 4 on the target server after the import.

The replication mechanism keeps track of all the previous imports for the target environment. During import, it omits versions that have already been imported to the environment. In the earlier example, versions 1 and 2 from the source server won't be imported to the target server during the second import because they were already imported during the first import.

This technique enables you to remove unnecessary versions on the target server during replication.

Example: The following example explains what happens if the Versioned objects option is set to Deployed.

Assume there are 2 versions of a property sheet on the source server, and only version 2 is used by the deployed process: Source 2.

Result: The replication procedure recreates this version on the target server: Target 1 (2).

If there is a snapshot referring to version 2 on the source server, it refers to version 1 on the target server after the import.

Back to top

See also: