DeployHub comes with a set of reusable Actions that can be invoked at various points in a deployment. An Action is a selection of Activities which are executed in sequence in order to provide the logic of the deployment. Actions are created with a graphical editor by simply dragging and dropping the Activities you want to use in the order you want to use them. On save, a new Action will be created.


In addition, a Custom Action can replace the usual Deployment Engine processing by calling an external script that performs its own deployment activities. Custom Actions can be used when the normal component-level deployment is not suitable for the deployment of the Application.


Actions can call Procedures and Functions. These Procedures and Functions can be:

  • Written in DMScript (DeployHub's Object-Oriented Scripting Language) – this is akin to a "Stored Procedure". DMScript has access to the DeployHub Object Model.


  • A script written in any scripting language supported by the Deployment Engine's operating system and held locally to the Deployment Engine.


  • A script written in any scripting language supported by the target Endpoint’s operating system and located on the target Endpoint.


  • A script written in any scripting language supported by the target Endpoint’s operating system and held locally to the Deployment Engine. When invoked, the script is automatically copied to the target Endpoint and executed there.


DMScript ships with several pre-installed Procedures and Functions. It is also easy to create your own and add them to the activities that can be used when creating a Components installation logic.


Actions can be invoked:

  • Before any Task in a Domain is executed: When the Task is created, a "Pre-Action" can be specified. This can be either an Action or a Function. The specified Action or Function is invoked before the Task is executed. If the Action (or Function) aborts or returns a non-zero return code, the Task itself is prevented from running. This can be used to connect to external systems to do "pre-flight" checks (for example, to notify a group of users that the selected Application Version is about to be deployed).


  • After any Task in a Domain is executed: When the Task is created, a "Post-Action" can be specified. The specified Action is invoked after the Task is executed. This can be used to connect to external systems to notify them that a Task has been executed (for example, to notify a bug-tracking system that an Application Version has been moved to a Testing state).


  • As a stand-alone Action that can be invoked from the DeployHub User Interface: The Action is associated with a "Run Action" Task. When invoked, the Action is executed. A user can right-click on the Domain to view the Task to execute the Action. Alternatively, they can right-click on an Application or a Component. In these circumstances, the selected object is pushed onto the Stack and is available via the $application or $component objects. See DMScript user guide for more information on the Stack.


  • Before an Application is deployed: When an Application is defined it can have a "Pre-Action" associated with it. This can be either an Action or a Function. When the Application is deployed, this "Pre-Action" is invoked first before any other operation.  If this Pre-Action aborts or returns a non-zero return code, the deployment itself will be prevented. This can be used to perform "pre-flight" checks (for example, to deny a roll-back operation and force the user to "fix-forward").


  • After an Application is deployed: When an Application is defined it can have a "Post-Action" associated with it. When the Application has completed deployment, this "Post-Action" is invoked. This can be used to connect to external systems to notify them that an Application has been deployed.


  • As a Custom Action for the Application: When an Application is defined it can have a "Custom Action" associated with it. This "Custom Action" is then executed to deploy the application. It is the responsibility of this Custom Action to deliver the code to the target Endpoint(s).


  • Before a Component is deployed to an Endpoint: When a Component is defined it can have a "Pre-Action" associated with it. When a Component is being deployed to an Endpoint, Component Items are processed, and the files are pulled from the Repositories and placed into the Dropzone. Any action defined as a Pre-Action to a Component is executed after the Dropzone has been populated from the Component Items but before those files are pushed to the Target Endpoint(s). A Pre-Action to a Component can be used to manipulate the files in the Dropzone before the files are delivered to the Target Endpoint (for example, by modifying configuration files).


  • After a Component is deployed to an Endpoint. When a Component is defined it can have a "Post-Action" associated with it. When a Component has been deployed (i.e. all the files from the Component Items have been pushed to the Target Endpoint) any "Post-Action" is executed. A Post-Action to a Component can be used to run scripts on the Endpoint after the files have been delivered (for example, to install SQL changes or restart the Application Server).


  • As a Custom Action for the Component. When a Component is defined, it can have a "Custom Action" associated with it. This "Custom Action" is then executed to deploy the Component. It is the sole responsibility of this Custom Action to deliver the code to the target Endpoint. Use a Custom Action when the delivery method differs from the usual "push files" mechanism – for example, invoking Ansible to install a piece of infrastructure or to issue a RESTful call to update the configuration of a load balancer.


The Actions tab is available from the Flows Main Menu item.


Creating and Deleting Actions

You can create a new Action by right clicking the Domain or Life Cycle Sub-Domain. A pop-up menu item will appear to create a ‘New Action in this Domain.’ Alternatively, you can delete an Action by right clicking on the Action in the tree structure and selecting the ‘Delete this Action from the Domain.’  

Finding where Actions are Used

To find out where (or if) an Action is used, right click on the Action in the left-hand tree view and select Show References. A pop-up box shows the Components, Applications, and Tasks which use that Action. Clicking on the reference will take you to the object where the Action is used.

Configuring Actions

Once created, the Action will need to be configured. Actions are made up from Activities within a Workflow. Activities include Procedures and Functions that are accessible in the Domain Hierarchy. You will need to define the Procedures and Functions that the Action will use prior to defining the Workflow. Alternatively, you can use the available Procedures, Functions, and other Activities that ship with DeployHub for defining the Workflow steps.


To configure the Action’s basic information, select the Action from the tree view, and click on the pencil icon in the right-hand corner.  This will bring up the General Dialog box for defining the Action’s basic information.

Workflow Tab

Actions are defined within the Workflow Tab. A tree view on the right shows all the categories available to be include in the Action’s Workflow. You can use the built-in activities for defining the Workflow steps or you can create new Procedures or Functions and have them available as activities to use.


The Workflow tab contains all activities that make up the Actions Workflow steps, linked together in the order they are to be executed. Each Activity in the Workflow has several Anchors where connections can be made – an Input Anchor (in blue) at the top of the Activity where the Workflow enters the Activity and zero, one or more Output Anchors where the Workflow exits that Activity.


Click on one of the Categories in the list to see the available activities. Expand a Category and then select the desired Activity to drag and drop it into the Action Workflow area. It appears as a box containing the name of the Activity. It automatically links to the nearest Activity with a free Output Anchor. An editor box opens automatically to set any input values required. If the dropped Activity refers to a Procedure or Function, then the input values will be the input parameters of the Procedure or Function. If the dropped Activity refers to a Function, then an additional Result field is presented. This needs to be the name of a Variable that receives the result of the Function.


You can connect Activities in any order you require. To do this, left-click and hold down the button on one of the Output Anchors, then drag the resulting line onto another Input Anchor. This connects the Activities together and determines the order for processing the Workflow steps.


The lines connecting Activities can be deleted by right clicking on the connector line and selecting “Delete this Connector”.


Some Built-in Activities have more than one exit point. For example the "if" Activity can be used to create conditional branches where different routes are taken through the Workflow dependent on the evaluation of an expression. In such cases, there are multiple output "anchors" with labels (for example, true and false) which indicate the meaning of the anchor. Connect the Activities to the appropriate Output Anchor.


Some Built-in Activities can contain other Workflows. When such Activities are dropped onto the Action’s Workflow area they are represented by a larger “box” containing a diagram showing another Workflow. Double clicking on such an Activity will “drill down” into that Activity and open up another Workflow editor. Such actions are typically “loops” (where the Workflow “inside” the loop is executed for each iteration through the loop) and “using” Activities (where everything in the Workflow is set to use a particular Stream, Dropzone, Component or Application).


There are Procedures and Functions that ship with DeployHub, such as the Windows function ‘listservices’ and the WebSphere ‘DeployWS’ control procedure. These are editable (by an administrator with access to the GLOBAL Domain) just as any User defined Function or Procedure would be. There are also some Activities that simply wrap around DMScript (such as "Loop through Array Keys") that are not editable.


When the Workflow is executed, it’s first converted into a DMScript Procedure. DMScript is DeployHub's built-in Object-Oriented Scripting Language. If you want to see what the generated DMScript will look like, right-click anywhere in the background of the Action Editor Pane and select "Show Generated DMScript". A window pops up showing the DMScript of the assembled Workflow.


You can also export the generated workflow as a Procedure. To do this, right-click anywhere in the background of the Action Editor Pane and select "Export as Procedure". This generates the DMScript and then exports it as a Procedure Export file. This can then be imported later into the workflow. You can use this technique to create DMScript procedures using a drag-and-drop editor.


NOTE: In the Workflow area, an object represents the currently selected Action. It is distinguishable by the arrow icon that appears in the object along with the word “Start”, and it is positioned in the top of the window. It can be moved horizontally to aid with Workflow layout. This Start Activity has a single Output Anchor which must be connected to the first Activity to be executed, otherwise DeployHub does not know where to begin, and the Workflow will fail.


Timeline Tab

This tab displays audit log entries for deployments that used this Action, including deployment number, Environment, Application, and how many days ago the deployment (or hours for all of today’s deployments) took place.

Commenting on an Action

Click on the ‘Comment’ link within each entry to open a text entry field just below the deployment information. There is a field labeled “Say something about this Action?” for comments and files. Entering text into this field activates the Add Message button. Click on this button to save the comment as a new audit entry.

Adding Documents to your Comments

Clicking on the paperclip button next to Add Message brings up a file explorer for multiple files to be selected and attached to the comment. Clicking on that paperclip expands the audit entry to show the files attached to the comment as hyperlinks. Clicking on the link downloads the file. This process is browser-specific. ‘Click to see earlier items’ link shows earlier entries in the timeline.

Subscribing to an Action

The Subscribe link places the audit entry into the User's personal timeline. Any comments added to the audit will appear in the Timeline tab of the subscriber’s home page.

Access Tab

This tab contains Groups, and the Users that belong to them, who have access to this Action. Click on a Group name in the Available Groups list and drag this into one of the lists to allow the Users in that Group access to View, Change, or Execute the currently selected Action. Access includes:


Access

Description

View

Allows the User to see the Action. If the User does not belong to a Group in the View Access list, the Action will not appear in the tree structure

Change

Allows the User to change the Action’s characteristics i.e. Name, Summary, etc.

Execute

Allows Users to execute this Action.

General Tab

The General tab defines basic information about the Action and allows you to add it to a specific category.


Field

Description

Name

A unique Name that describes the Action. This cannot be the same as a reserved word within DMScript (see the DMScript chapter), as it will cause a syntax error when executed.

Summary

A brief description of what the Action does.

Category

Categories are used to arrange Actions in an orderly manner. Assigning a Category to an Action allows lists of Categories to be used throughout DeployHub. Clicking on an individual Category expands the list and shows all Actions that belong to that Category.

Owner

The User or Group name of the Action’s owner. The default owner is the User who created the Action. When editing this field, the Owner Type field is available which includes Owner and Group as choices. Selecting one of these causes the Owner field to display either Users or Groups to choose from.

Created

When the Action was created (read-only).

Modified

When the Action was last modified (read-only).