The following recommendations apply in an environment where separate, unique galaxies exist at different production sites, and where standardization is required across the sites.

Templates can be reused in different galaxies (just as they can be reused in the same galaxy) to create multiple instances. The important difference in this scenario is that change propagation in a single galaxy is a simple process where locked features are automatically propagated to instances, whereas a multi-galaxy environment requires formal procedures be defined and implemented to manually update and maintain templates.

The following recommendations describe performing updates/synchronization in a structured and repeatable manner:

Best Practice

• Create a Master Galaxy for development purposes. This Galaxy contains the master template library with the latest revisions for all of them. When new galaxies must use any of these templates, ensure they include the latest revisions.
• Create a "staging" engine for testing purposes. Whenever possible, deploy this engine on a machine that has no impact on a real production system. Once an object design has been tested and its functionality verified, it can be distributed to other sites.
• Export .aaPkg packages (cab files) that contain the necessary templates out of the Master Galaxy, then import them into the new production Galaxies.
• Create local templates that derive from the master at each production galaxy. Any changes or specialization required should be implemented in the local template. Make use of toolsets to separate the master templates from the local templates; it is even recommended to hide the master template toolset in the production galaxies and treat them as if they were Read Only templates.
• Packages with exported templates do not include any logs documenting changes to the base templates, so all changes must be done in the master galaxy and properly documented upon check-in after editing objects.
• The Import Preferences dialog box (opened when importing a package with templates) includes options to handle version mismatches and name conflicts. In a multi-management environment where a package from the Master Galaxy is updating templates that already exist in production galaxies, select the Overwrite option to handle version mismatch.
  
  The Overwrite option will only work if the version of the object being imported is higher than the current version; the object version is stored in the ConfigVersion attribute that is present in all templates and instances.
• Changes made on the local templates should be verified and validated before they are merged into the master template on the development Galaxy.
  
  If it is determined that the features in local templates should be implemented in the master templates, any new functionality (i.e. attributes or scripts) must be manually implemented on the master templates and properly documented.
  
  After manual implementation and documenting, a new package can be exported in order to update all production galaxies with the new version of the templates.