Deployer 10.11 | Deploying a Project | Rolling Back Target Servers
 
Rolling Back Target Servers
If deployment to a target server fails and the target environment is in an inconsistent state, or a deployment is successful but the deployed assets are not working as expected, you can use Deployer's roll back feature to undo the deployment. When you roll back a deployment, Deployer rolls back the target server to the last checkpoint generated for the project. For more information about generating checkpoints, see Generating a Checkpoint.
You can set Deployer to roll back target servers automatically or you can roll back target servers manually after deployment.
Deployer automatically rolls back target servers for runtime-based projects in these cases:
*You set the Rollback on Error project setting to Automatic (see Settings for Runtime-Based Deployment Projects). If the deployment fails on a target server, Deployer automatically rolls back that target server.
*Deployment failed to a target group whose Rollback All on Failure setting is Yes (see Creating Target Groups). If deployment to any server in such a target group fails, Deployer automatically rolls back all servers in the target group.
Deployer automatically rolls back the target servers for repository-based projects when transactional deployment is enabled for the project and deployment fails. For more information about enabling transactional deployment, see Creating a Project.
For runtime-based projects, you can roll back target servers manually at any time after deployment if you performed both of the following:
*You set the Rollback on Error project setting to Manual.
*You did not deploy to a target group whose Rollback All on Failure setting is Yes.
For repository-based projects, you can roll back target servers manually if you performed either of the following:
*You enabled transactional deployment to create an automatic checkpoint through the Enable Transactional Deployment parameter.
*You generated a manual checkpoint for the project.
*To roll back target servers manually
1. In the Deployment Candidates list, click in the Rollback column.
Deployer displays the rollback report in the right-hand pane in the Deployment History area.
2. To display the rollback report, click next to Rollback in the Report Type column. The report is also available under the name project_name_auditReport_reportID.xml in the Integration Server_directory \instances\instance_name\packages\ WmDeployer\pub\projects\project_name\targets\deployment_map\reports folder, where project_name is the name of the project and deployment_map is the name of the deployment map.
If you rolled back an IS & TN deployment set, the following apply:
*If the Activate After Deployment option for a package was set to Inbound Only, the report will warn that the package is not present on the target Integration Servers. You can ignore this warning.
*If the deployment set included webMethods files, the directory structure for those files remains in the webMethods installation directory on the target servers. You can delete the directories manually.
*If you deployed Trading Networks document attributes, field definitions, binary types, or profile security data, Deployer does not roll them back.
If you rolled back a ProcessModel deployment set, the rollback behavior varies, as follows:
*For process models you deployed that were versions of existing process models on the target servers, Deployer rolled back the deployed versions from the target servers.
*For deployed process models that were new on the target servers, Deployer disables the deployed process models but does not remove them from the target servers. However, Deployer removes the Integration Server assets from the target servers on rolling back a project with deployment sets that include IS assets for the process models. If a process instance for the rolled-back process model exists on a target server, this behavior could result in issues.
If you rolled back Universal Messaging assets, the rollback behavior is as follows:
*Deployer will not roll back the assets if the port is already being used by another existing interface.
*Deployer does not roll back nested security groups. For example, if group1 contains group2, the rollback will not restore the nested group2.