This section documents guidelines for deploying modeled customizations. By “deploying” in this context we mean copying the customizations from one system to another – from a source to a destination. The process you use will depend on the actual source and destination of the customizations.

Modeled customizations, when built, will impact the installation in three primary ways:

Additionally, you may have added entries to site.xconf to register services.

In any case, you must:

One common scenario is an environment where the source is a Development system and the destination is a Production system. In this scenario we can make assumptions that simplify the deployment process. Most importantly, we assume the development and production systems are essentially clones.

This section uses “Development System” to refer to the source where the customizations are being developed. “Production System” refers to the destination that is either currently being used by the customer for their production work, or the new production system that is being developed as part of a new deployment, migration or upgrade. Your environment may include other systems that need to be maintained such as a test system or staging (pre-production) system. All the steps described below for deploying customizations to production apply as well to the other systems – as long as the same assumptions apply.

In this scenario we assume that the development and production systems are clones, and that as you make changes to the development system, you can copy them to the production system. For that reason it is important that the production system and development system share the same fundamental state (the same products are installed, the same patches, and all are at the same release level) or your classes may be incompatible, your registry files may contain extraneous entries (or drop important ones), and your database schema may be incorrect.

If these assumptions are met, then you can follow the guidelines in the following steps:

Deploying your customization from your source to your destination entails replaying your actions in the source environment on the destination system. One strategy would be to simply copy over the source and rebuild it on the destination system. This strategy, however, necessitates compiling on the destination system, but if that is your production system then that is probably not acceptable.

Another strategy is to use a version control system, like Git or Subversion, putting your entire load point under it, allowing the version control system to tell you how your customization impacted the installation, and merge over the changes.

If the destination system includes customizations that are not part of the source system you are deploying, you will need to create incremental registry files that can be merged into the registry files in the destination system. The registry_diff target can be run against the source system files to produce the incremental files to merge into the destination system with the registry_merge target.

The registry_diff target can be run from the Windchill shell of either system, as long it has access to the required folders, described below.

Ideally you would have preserved the original state of your registry files before doing any customization. If not, then to access your original registry files you may need to unregister your customized classes, preserve the registry files as your base, and then rebuild your customizations. For example, to unregister your customized classes that begin with the prefix “ext.”:

Remove lines beginning with “ext.” or containing “=ext.”:

Note: This will match any key or value that begins with “ext.”.

For additional usage examples execute: ant -f <loadpoint>/bin/tools.xml model_uninstall.help

The registry_merge target must be run from the Windchill shell of the destination system, and it must have access to the files generated by the registry_diff target.