Choosing commit and undo options

Commit and Undo Options let you customize the behavior of a Deploy Job during its Commit phase and during the undo of a deployment.

To choose commit options

1. Check Auto rollback to leave the destination host unchanged should the Commit phase fail.
   When you check this option and the Commit phase fails for any reason, the Deploy Job is automatically rolled back, leaving the destination host unchanged. If you do not check this option and the Commit phase fails, the deployment aborts and does not roll back any transactions that are part of the deployment.

   Note

   Using the BLPackage editor, you can customize the behavior of a deployment so individual commands in the deployment can fail but the overall deployment continues (see Adding-an-external-command-to-a-BLPackage).

2. Check Allow rollback to leave rollback files on the target server so they can potentially be used later to undo a deployment. In some situations, the rollback files left on the target server can be large.

   Warning

   Each run of a Deploy Job generates a unique set of rollback files. Because these files can be large, if you are running multiple Deploy Jobs and you choose to store rollback files by selecting this option, you may be generating extremely large amounts of data. In a situation like this, you should set up a prudent retention policy for both storing job runs and executing your data retention policy. Job run data should only be stored as long as you need it. For example, if you run a Deploy Job daily, you may only want to store job run data for one or two days. See Cleaning-up-TrueSight-Server-Automation-data for more information about data retention.

   Rollback files reside under agentInstallDirectory/Transactions. 

   New(For Microsoft Windows) Logs of every deployment is available in STDeploy.log rolling file in agentInstallDirectory\Transactions\shavlik\Logs directory. This is irrespective of whether Allow rollback option is selected or not for Deploy Job during its Commit phase.
   
   For UNIX, by default this location is:
   /opt/bmc/BladeLogic/NSH/Transactions
   
   For Microsoft Windows, the default the location is:
   C:\Program Files\BMC Software\BladeLogic\RSCD\Transactions
   
   TrueSight Server Automation provides a mechanism for storing rollback information in an alternate location. For details, see Configuring-the-location-of-the-transactions-directory.

3. Check Preserve staging area on failure if you want to keep the data copied to a staging area for the BLPackage even though this Deploy Job fails.
   By default a Deploy Job deletes the staging directory on a target server when a failure occurs during any phase of the job. Preserving a staging area can potentially leave large files on a target directory after a job failure.

4. Check Overwrite read-only files to instruct a server to overwrite read-only files when read-only files are encountered during the Commit phase.

   Note

   This option is only for copying a file onto a target with an existing file that is currently read-only. The option does not affect any asset type other than the file asset and the copying of the entire file. For example, if there is a change to a configuration file and the configuration file asset is used, the override option does not attempt to alter the file state to allow configuration file updating and editing. However, if the entire configuration file was packaged as a file asset, then the file to be copied onto the target and the read-only option are temporarily changed, assuming that the user and role being deployed have appropriate permissions.

5. If you are deploying to Windows machines, check any of the following options under Windows-only Options:

   Option	Description
   Ignore presence of "copy on boot" files	Instructs a server to begin the Commit phase even though a server requires a reboot to copy over existing locked files. Clearing this option means the Commit phase does not begin if locked files requiring a reboot exist.
   Copy locked files (do not treat locked files as error)	Instructs a server to create "copy on boot" files when locked files are encountered during the Commit phase. These are files that are copied and then overwritten after a reboot. Note that a Deploy Job only creates "copy on boot" versions of read-only files if the Overwrite read-only files option (see above) is checked. Clearing this option means the job repeatedly attempts to copy the files being modified. The job attempts to copy the files 25 times, with a two-second wait between each attempt. If files are still not successfully copied, the job generates an error and fails.
   Register COM components	Commit Phase — Registers COM objects during the Commit phase. When a deployment adds a file with an extension of DLL, EXE, or OCX, the job determines if the file is a COM object. If it is, the deployment registers the new object during the Commit phase. Undo Phase — Registers COM objects during the Undo phase. If the Commit phase of a job run removes a file, the file is restored when that job run is undone. If the file has an extension of DLL, EXE, or OCX, the job determines if the file is a COM object. If it is, and this option was selected during the Commit phase of the job run being undone, the file being restored is registered.
   Unregister COM components on delete	Commit Phase — Unregisters COM objects during the Commit phase. When a deployment removes a file with an extension of DLL, EXE, or OCX, the job determines whether the file is a COM object. If it is, the deployment unregisters the object during the Commit phase. Undo Phase — Unregisters COM objects during the Undo phase. If the Commit phase of a job run adds a file, the file is removed when that job run is undone. If the file has an extension of DLL, EXE, or OCX, the job determines whether the file is a COM object. If it is and this option was selected during the Commit phase of the job run being undone, the file being removed is unregistered.