The Delivery Pipeline defines a continuous delivery process for driving continuous deployments. You can use DeployHub independent of a continuous delivery engine such as Jenkins Blue Ocean, GitLab, Bamboo, or GitHub Actions. Alternatively, you can integrate to these types of tools allowing DeployHub to manage the continuous deployment steps and report back to these tools, logs, and success/fail messages.

Building your Delivery Pipeline

The Delivery Pipeline contains all information for Life Cycle Sub-Domains concerning the deployment of Applications and their movement development through production release. It is designed to show and keep track of the procession of Applications through the continuous delivery pipeline, as well as the deployment of Applications into Environments. Keep in mind that when dealing with software lifecycles within DeployHub, parent Domains contain Life Cycle Sub-Domains, and these contain Applications and Environments. All Move, Deploy, and Request Tasks discussed in this section are utilized in the tree structure by right clicking on the Applications within Lifecycle Domains. The results are viewed in the Delivery Pipeline tab for the parent Domain.


The Delivery Pipeline tab is only available in Project Domains that contain Life Cycle Sub-Domains. Applications can be moved forward or backward between Development, Test, and Production Life Cycle Sub-Domains, which have been arranged within the parent Project Domain in the correct continuous delivery pipeline order. Therfore, there could be three Life Cycle Sub-Domains in the parent Project Domain named appropriately, i.e. Dev, Test, and Prod, in that order.

Delivery Pipeline Process

Applications can be moved between Life Cycle Sub-Domains with a Move Task. Any User with access to that specific Move Task, which designates which Project Domain the Application can be moved to, can use it to move the Application. However, if there is an Approval Task present in the Project Domain, you need approval before it can be moved to the next Life Cycle Sub-Domain as designated by the Approval Task.


If a User does not have access to the Move Task, that User can make a Request Task. Then a User with access to the Request and Move Tasks can grant access to the Move Task. The Approval Task also designates which Life Cycle Sub-Domain the Application can be moved to, so that in order to move an Application, both the Approval and Move Tasks must designate the same destination Life Cycle Sub-Domain.  


If an Application has been approved by a User with access to the Approval Task, it will appear in the boxes under the Delivery Pipeline tab and will be shown with a green checkmark, and the Application can then be moved to the designated Life Cycle Sub-Domain. If it has been rejected, it will be represented with a red ‘X,’ and it cannot be moved.


An Application can be moved to another Life Cycle Sub-Domain by right-clicking on the Life Cycle Sub-Domain within the tree structure and then selecting the Move Task. Once it has been moved, it is represented with neither a checkbox or ‘X.’ These icons only work when moving forward. When moving backward through Life Cycle Sub-Domains, there are no icons displayed in the boxes under the Delivery Pipeline tab.


If an Application is deployed, it appears in one of the lower boxes which represents the Environment it was deployed to, and the Application no longer appears in the upper box titled Undeployed Applications. Environments are stacked vertically under the Life Cycle Sub-Domains in which they belong.