Deploy Job - Phases and Schedules
The Phases and Schedules panel lets you choose the deployment phases that should occur during deployment of a software package or BLPackage. It also lets you schedule the execution of a job.
The Phases and Schedules panel prompts you for the following categories of information:
If you are defining a Software Deploy Job, you can only schedule the job as a whole. If you are defining an advanced BLPackage Deploy Job, you can schedule individual phases.
Using the Phases and Schedules panel, you can choose to stage a deployment by delivering a package directly to a target or by staging indirectly, meaning the package is copied to a server designated as a repeater, and the repeater pushes the package to multiple targets. There are several reasons to stage indirectly. If you stage directly, you may be copying packages to a large number of hosts, which can saturate a network with data. By staging indirectly, you can segment your network and help spread the load over multiple hosts and sub-nets. If you are staging through a thin pipe, for example a Wide Area Network (WAN) like the Internet, you may have throughput issues. Staging to repeaters can shift the bulk of a deployment to a much faster local area network.
During staging, a package is copied to a staging directory, which stores a package until it is applied to a server during the Commit phase. Each server's STAGING_DIR property identifies the staging directory for that server. By default the staging directory on Windows is \temp\stage. On UNIX it is /var/tmp/stage. Using a local directory on a target server eliminates the need for moving data through a network during the Commit phase and thus shortens the maintenance window needed for committing a package to a server.
Optionally, you can identify a network location for a staging directory by assigning a network location to the STAGING_DIR property. Using a network staging location means a package only needs to be pushed once to the staging directory. When the Commit phase of a Deploy Job runs, the job pulls the package from the network location and applies it to the target.
If you are staging indirectly, you must specify the repeater that each target server uses. Each target server's REPEATER_NAME property identifies the repeater relaying data to that server.
Objects being deployed are stored on a repeater after the Deploy Job completes. Subsequent Deploy Jobs can use the same objects without copying them to the repeater. When you run an indirect Deploy Job, TrueSight Server Automation searches the cache on the repeater to find the objects being deployed. If an object exists, the system compares the object's MD5 checksum to confirm that it is the same as the object being deployed. If the object does not exist or it is not the same, a new object is copied to the repeater.
When choosing to set up an indirect deployment, you should also consider whether your source files are network-based. If you are using a network-based deployment, you can instruct the agent on a target server to mount the server where the source files are located. From there the agent can deploy the files directly to the target server. In a deployment like this, using a repeater may not provide any benefit.
The appearance of the Phases and Schedules panel varies depending on whether you are defining a Software Deploy Job or a basic or advanced BLPackage Deploy Job.
Where to go from here