Deployments deliver Applications to an Environment associated with one or more Endpoints. These Endpoints represent the actual, container, physical, or virtual servers within an enterprise’s data center. There are four objects deployed to an Environment:

  • Application Base Version: A collection of Component Versions. These are collections of Component Items, referencing files within a Repository copied to an Endpoint or are the scripts copied to an Endpoint and/or executed against an Endpoint’s operating system or database.

  • Application Version: This is when the original has been changed by adding, removing, and/or changing Component Versions.

  • Release Base Version: (Only available in DeployHub Pro) A collection of Application Base Versions and/or Application Versions. This provides a way to organize and deploy several different Application Versions into an Environment.

  • Release Version: (Only available in DeployHub Pro) This is a copy of a Release Base Version which has been changed by adding, removing, and/or changing an Application Base Version or Application Versions from the original.

For the sake of simplicity, these objects are Component Base Versions and Component Versions, without the words ‘Base Version’ or ‘Version’, since they all behave the same and have the same attributes.

Deployment processing defaults to the configuration of the Component Item. This is the source location where the files and scripts reside, and the target Endpoint to which the files will be deployed. When you execute a deployment, DeployHub will move the files within Component Items from the source location to the target Endpoint. Default processing can be enhanced by Actions that allow you to refine the way the deployment will occur. Actions themselves contain Procedures, Functions, and other Actions which allow you to develop highly functioning and re-useable processes that can be shared across the Domain (or Life Cycle Sub-Domain) to which they belong.

Executing Deployments with an External Script

You can choose to bypass DeployHub’s deployment processing using a Custom Action. This can be used to call other tools such as Chef or Puppet to manage infrastructure updates. A Custom Action will call these types of external scripts. A Custom Action is defined by placing the name of a DeployHub Function, Procedure, or Action with the name and location of the external script in the Custom Action field of a Component or Application.

A Custom Action is used within Applications and Components to take over the normal process of a part of a deployment. When a Custom Action is designated within an Application or Component, any designated Pre or Post-Action is ignored and not executed during the deployment. Any file(s) designated within Component Items belonging to the Component are not deployed as they normally would be. When a Custom Action is used, all deployment processing is handed over to the Custom Action. If a DeployHub Procedure or Action is used, the Procedure or Action is called, and control is then returned to DeployHub. If an Action is used, it can use one or more DeployHub Procedures, Functions, and Actions, in a predetermined order.

A good use for a Custom Action would be the installation of a commercially available or in-house software package that has been around for a while within the I.T. infrastructure, and the installation has been fine tuned to the point that a single executable can be called in order to install it. In this case, a DeployHub Application could contain a Component with a Custom Action that calls the executable at the correct point within the deployment. The Application itself could also contain the Custom Action, with no need to involve Components. It all depends on the approach taken to perform a given deployment. An Action can contain all the logic to remain within a loop and check for the presence of a condition that signals the installation is complete (i.e., a file exists within a given directory) before moving on the next step of the deployment.

NOTE: Custom Actions allow you to execute the existing one-off deployment scripts and can support an easy transition to using DeployHub.

DeployHub supports on-demand deployments and scheduled deployments using the Environment’s Calendar. You can also perform a pre-flight check of each deployment.