Processing Logic

A DeployHub deployment moves files and scripts from source Repositories to a target Environment which contains one or more Endpoints. This is performed via Releases or Applications, which contain Components, which in turn contain Component Items. These Component Items each reference a Repository, whose files and scripts are placed into a Dropzone. Customized Actions can be used to manipulate the files (edit, delete, etc.) within the Dropzone before being deployed, in a predetermined order, to every Endpoint within the Environment.  A Release is a collection of Applications.

Applications contain one or more Components, which contain one or more Component Items. These refer to a single Repository, which retrieve one or more files/scripts to be deployed. Components are linked together within an Application in the order to be deployed. Component Items are linked together within Components. Components and Component Items can be dragged and dropped using a design pallet to define the order to be deployed.

Application Versions are created from Application Base Versions once changes are made to them. They are linked together in the order created for the purpose of Rolling Forward and Rolling Back between versions.

DeployHub performs all deployments in an Agentless mode. No remote agents need be installed on the target Endpoint to execute deployments.

A DropZone is created for each Component during a deployment. Files from the various Component Items within the Component are placed into the DropZone. After all of the Component Items have been processed for the Component, the files within the DropZone are deployed to the Endpoints within the selected Environment. The DropZone is then deleted. Another DropZone is created for the next Component, until all Components have been deployed for the Application. The next Application version is deployed, and the process starts all over again.

DeployHub uses ftp, ftps, sftp, or Windows protocol to transfer files. When a deployment is executed, DeployHub performs the following steps:

  1. The first Application is moved onto the stack. Any Pre-Action for the Application will be executed at this point.

  1. The first Component is moved onto the stack.

  1. A DropZone is created for the Component.

  1. The first Component Item for the current Component is processed. Files from the Repository referenced by the Component Item are placed into the DropZone. This continues until all the files from all the Component Items are placed there.

  1. A Pre-Action for the Component is performed with usually one or more scripts to manipulate files within the DropZone before deploying them.

  1. The DropZone files are placed into every Endpoint within the Environment where the Endpoint type is the same as the Component type. Keep in mind that a Component can have only one type and an Endpoint can have many types.

  1. A Post-Action for the Component is performed for cleanup or additional manipulation of files. It is run against every Endpoint with the same Component Type as the Component.

  1. If there are more Components, steps 2 through 7 are performed again after a new DropZone is created.

  1. Pre and Post processing Actions defined in the Application or Release (DeployHub Pro only), such as stopping and starting a WebSphere Server, are performed on each of the target Endpoints in the Environments. Any errors found at the delivery level are logged and may fail the deployment. All logs are reported back to DeployHub and recorded in the History Tab for each Application or Release.

NOTE: A  Successful Deployment Email Template will notify recipients when the deployment proceeds normally.: Exceptions cause the deployment to be marked as "failed". The Failed Deployment Email Template assigned to the Application will notify recipients of that failure. Various problems, such as a missing directory on a filesystem Repository type, or an operating system error which prevents the creation of a DropZone directory, will result in a failure. Missing files, conversely, would not necessarily cause a failure since DeployHub has no way of knowing whether the files are supposed to be there or not. Under these circumstances, Post-Actions that have been assigned to the Components could be designed, among other things, to verify what has been deployed. An Abort could be issued from within a Post-Action, which would cause the deployment to be marked as ‘failed’.

NOTE: The Base Directory for a Component can either be absolute, i.e. 'c:\main' for Windows or '/main' for Linux/Unix, etc., in which case it replaces the Base Directory for the Endpoint. If the Component's Base Directory is relative, i.e. 'SomeFiles\SomeMoreFiles', then it is appended to the Endpoint's Base Directory,

For example: 'c:\main\SomeFiles\SomeMoreFiles'. If the Component Item's Target Directory has a value, it is always appended to the end of whatever value has been created from the Base Directories of the Endpoint and Component.

The following diagram shows how the deployment process within DeployHub works: