Phases of a Deploy Job

A BLPackage Deploy Job has three phases:

A Software Deploy Job only has two phases:

• Staging phase
• Commit phase

Simulate phase

The Simulate phase performs a test run of a deployment without deploying the package. The test run verifies the XML instructions that define the BLPackage and performs tests to ensure the validity of those instructions. For example, if the BLPackage is deleting a file, the test run ensures that the file exists. A test run also checks environmental requirements. For example, it determines if you have the appropriate access level and if the target is running in multi-user mode, which is necessary when a job is defined to use agent mounting when deploying files.

The Simulate phase is optional, and it is only available when deploying BLPackages.

Staging phase

The actions that a Deploy Job performs during the Staging phase depend on whether you are deploying assets stored in the Depot or network-based assets.

Depot assets

If assets being deployed are stored in the Depot, a Deploy Job copies the contents of the packaging directory to a staging directory on a target server or repeater. If the target is a component, the staging directory can be located on the server associated with the target component.

The contents of a packaging directory are:

• For a BLPackage: an XML instruction file; all server objects being added, replaced, or deleted; and grammar files, if applicable.
• For a software package: an XML instruction file; installation files; support files (if any); and grammar files, if applicable.

The packaging directory is created when you add a software package or BLPackage to the Depot. If the contents of a BLPackage are soft-linked, the software or server objects referenced by the BLPackage are not added to the packaging directory. Instead, they are copied to a staging directory on a target server or repeater when the Deploy Job runs.

Network-based assets

If the assets being deployed are network-based, the Deploy Job copies the XML instruction file and any applicable grammar files to a staging directory on the target server. (If the target is a component, the staging directory can be located on the server associated with the target component.) The Deploy Job then uses one of the following approaches to access all other required assets:

• The Application Server mounts (for UNIX) or maps (for Windows) a network host and copies all assets from that host to a staging directory on the target server or repeater. From there, the source files are deployed to the target server.
• The agent on the target server mounts or maps a network server and deploys the assets directly from that network location to a target server. For UNIX target servers, the job creates symbolic links in a staging directory. The links point to the actual files being deployed, which exist on the mounted server. Creating links lets the deploy process act on those files as if they reside in the staging directory. For Windows, the job uses the full paths to all network-based assets so the job does not have to perform further actions in this phase. Note that only target servers can mount or map network hosts; repeaters cannot.

To mount a UNIX server, the agent uses the NFS protocol, and you must have root permission on the network server. To map a Windows server, the agent uses SMB and you must provide all necessary connection information (domain, user name, and password) in the URL of the server to be mapped.

Commit phase

The Deploy Job applies the package to the target component or server by running an install command (for a software package) or the appropriate add, replace, and delete commands (for a BLPackage).

If the Deploy Job definition calls for rollback, the job creates a subdirectory in the following location:

agentInstallDirectory/Transactions/rollback

where agentInstallDirectory is the directory where the agent is installed, Transactions is a directory used to store rollback information, and rollback is a directory created for a particular job. For each instruction that acts on a target, the Deploy Job makes a copy in the rollback directory of the original object that the job acts on. For example, for each file that is replaced, the Deploy Job copies the original file to the rollback directory. These copies are used to roll back the Deploy Job and restore the server to its original state. For software packages, a Deploy Job provides the choice of not storing rollback files, as they are not always needed to undo a deployment. Rollback files remain on a target server until you actually roll back a deployment or you manually remove them.

Files in the Transactions directory can become large. BMC Server Automation provides a mechanism for storing most transaction information in an alternate location for a particular target server. For details on this procedure, see Configuring the location of the transactions directory.

Finally, to clean up, the Deploy Job removes the staging directory, including any links it contains. Note that a Deploy Job gives you the option of keeping the contents of the staging directory if the job fails. If a job does not fail, the staging directory is always removed. Also, after a job completes, all mounts and maps to other servers are undone unless they are in use by another Deploy Job.