Over the past few weeks, we have been re-evaluating our recommendations for deploying production environments and have developed a new recommendation.
Recommended practice for deploying a Rhythmyx production environment is to copy a stable development tree to the target location; a dump of the stable database should be restored to the target database location.
Once the production server is in place, enhancements and new design elements should be implemented in the development environment and, after testing, deployed to the prodcution environment using Multi-Server Manager.
The document Setting Up the Production Environment has been revised to reflect this new recommendation.
Would this new recommendation help to solve the MSM issues raised in Moving Content between servers? and Packaging Content ?
We have discovered a deployment scenario that requires some additional attention.
The scenario is deploying a development environment to production, then deploying that production environment back over the development environment.
Development > > Production >> Development
If any MSM archives have been deployed to the production environment before it is redeployed over the original development environment, subsequent deployment of MSM archives from the development environment to the production environment will not behave correctly. Instead of updating the existing design elements on the production server with changes from the development server, the design elements will be added to the production server as new design objects. This behavior occurs because the original ID mappings between the development environment and the production environment have been invalidated by the redeployment of the production server.
For example, assume that you created a new Template in development with the ID 301. When the Template is initially deployed to the prodcution environment, it is assigned a new ID (say 1021). When you redploy the production environment over the development environment, the original Template ID (301) is overwritten with the ID from production (1021). If you subsequently attempt to deploy the Template from the updated development environment to production, no mapping exists for the development Template with the ID 1021, so MSM adds the Template to the production environment as if it were a new Template.
To prevent this problem, if you overlay a source environment (such as a development environment) with a target environment (such as a production environment), you need to clear the ID mappings in the target environment, and remap them when you deploy your MSM packages.
To clear the ID mappings, in the Repository database, delete all rows from the table DPL_ID_MAPPINGS.