Best practices for export / import

Follow these guidelines when exporting and importing workspace logic.

Exporting and importing collector workspaces

A workspace can include multiple trigger systems, but it is a good practice during the development and test phase to use a different workspace for each trigger system.

When you have tested all of your trigger systems in the development environment, you can then use component references to copy them to one collector workspace.

You can then export the collector workspace, import it into your production environment, and deploy it. Because the utility includes dependencies in the export, there is no need to import all of the workspaces referenced by the collector workspace.

Partial imports

You might import only a subset of your development workspaces. If a workspace that was affected by changes made in development exists in your production environment but is not updated during an import, you should not redeploy it.

The old deployment of the affected workspace should continue to function as usual, unless data sources used by that workspace have changed.

Changes in the production environment

In some exceptional circumstances, it might be necessary to make a change to a component in the production environment. If you do this, be sure to make the same change in the development environment so that your change is not overwritten during the next export/import cycle.

If you make a change in a stateful component such as a Pattern in your production environment, and you make same change in development, note that the state of the component will be different in the two environments.