Phases of a Deploy Job
A Deploy Job has three phases:
Simulate phase
The Simulate phase performs a test run of a deployment without deploying the package. The test run verifies the instructions for the package and performs tests to ensure the validity of those instructions. For example, if a BLPackage is deleting a file, the test run ensures that the file exists, and if a BLPackage is deleting a service, the test run ensures that the service does not have any dependent services. A test run also checks environmental requirements. For example, whether the staging directory on the target has enough space to store the payload files, and whether all requirements are met for the various selected job options.
The Simulate phase is optional.
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. (For more information about soft-linked objects, see Working-with-soft-linked-objects.)
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. TrueSight 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.