| title | linkTitle | weight | description |
|---|---|---|---|
Customize Your Actions |
Customize Your Actions |
30 |
Understanding and Adding Actions for defining your deployment logic.
|
An Action is a selection of Functions and Procedures which are executed in sequence in order to provide the unique logic required for the deployment of each Component. You can create Actions or use the Built-in Actions. Actions are created with a graphical editor by simply dragging and dropping the Procedures and Functions that make up your Action.
In addition, a Custom Action can replace the usual DeployHub deployment engine processing by calling an external deployment engine or scripts that perform the deployment steps (Helm for example).
Actions are used to customize DeployHub around deployments, and Tasks. For most users, no configuration of Actions is required. However, if you want to use your own deployment scripts, then you will need to use a Custom Action. This section will get you started on creating your own Actions.
DeployHub comes with a set of reusable Built-in Actions. An Action includes a set of Functions and/or Procedures which are executed in sequence to provide the logic of a Component's deployment. Actions can also be used as Pre or Post deployment steps to an Application or Release.
Actions depend on Procedures and Functions to do the work. If you want to create a new Custom Action, you will need to define the Procedures and Functions that the Action will use before you create the Action. Alternatively, you can use the Built-in Actions, Procedures, and Functions, that ship with DeployHub for defining the Steps of your new Action. For most user, the Built-in Actions will be sufficient for working with standard environments like Docker Containers.
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 call Functions and Procedures that execute external process such as Helm or Ansible. Functions and Procedures can be:
Actions can be implemented in many ways including:
-
Written in DMScript - DeployHub's internal deployment scripting language. DMScript has access to the DeployHub Object Model. 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 your Components installation logic. For more information see Dmscript.
-
A 'local' script - written in any scripting language that is supported by Linux, and executes in the DeployHub Container mounted from the Docker Host.
-
A 'remote' script - written in any scripting language supported by the target Endpoint's operating system and accessible to DeployHub. If allowed, the script is automatically copied to the target Endpoint and executed there. (Note: Copy remote must be set to TRUE at the Function or Procedure Level).
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 a Procedure or a Function. The specified Procedure or Function is invoked before the Task is executed. If the Procedure or Function aborts or returns a non-zero return code, the Task itself is prevented from running.
-
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 others 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 Stack for more information.
-
Before an Application is deployed: An Application can be defined as having a "Pre-Action." 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.
-
After an Application is deployed: An Application can be defined as having a "Post-Action." When the Application has completed a deployment, this "Post-Action" is invoked. This can be used to connect to external systems to notify others that an Application has been deployed.
-
As a Custom Action for the Application: An Application can be defined as having a "Custom Action." This "Custom Action" is then executed to deploy the Application. It is the responsibility of this Custom Action to deliver the update to the target Endpoints.
-
Before a Component is deployed to an Endpoint: A Component can be defined as having a "Pre-Action." When a Component is being deployed to an Endpoint, the Component is 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 Components but before the Component is pushed to the Target Endpoints. A Pre-Action to a Component can be used to manipulate files in the Dropzone before the files are delivered to the Target Endpoint (for example, a modification to a configuration file).
-
After a Component is deployed to an Endpoint. A Component can be defined as having a "Post-Action." When a Component has been deployed 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 to it. This Custom Action is then executed to deploy the Component. It is the sole responsibility of this Custom Action to deliver the update 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.
From the Action menu option to the left of the DeployHub main panel, you will be taken to a list of all available Actions which you have access to based on the Domain. You can also use the Filter bar, represented by a funnel icon, to reorder your Actions List View. You can filter on:
- Domain
- Action
The Action List View has the following Tabs.
| Tab | Description |
|---|---|
| Refresh | Refreshes the browser. |
| Add | Allows you to Add a new Action. |
| Delete | Deletes the selected item. |
From the Action List View, double click on the Action to view the details.
The Dashboard view displays all information related to a specific Action.
| Details | Description |
|---|---|
| Full Domain | The fully qualified Domain to which the Action belongs. |
| Name | A unique Name that describes the Action. |
| 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. You can add a new Category by simply adding it to the list using the entry field. Pre-defined Categories include: |
| Owner Type | User or Group |
| Owner | The User or Group name of the Action's owner. The default owner is the User who created the Action. |
| Created | An auto generated date when the Action was created (read-only). |
| Modified | An auto generated date when the Action was last modified (read-only). |
| Display Name | You can use this field to create a more user friendly name for your Action |
The Access Section allows Users within designated Groups to update the Action_ in various ways. To add a Group to one of the access lists, drag and drop the Group from the Available Groups list onto desired access list. All Users who belong to a Group that appear in one of the Access lists will be granted access to the Action in the following ways:
| Access | Description |
|---|---|
| View | Allows Users 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 List View. |
| Change | Allows User to change the Action’s characteristics i.e. Name, Summary, etc. |
| Execute | Allows Users to execute this Action. |
NOTE: DeployHub Team has only two Groups, Administrators and Users. If you need more granularity in your UserGroups, you will need to upgrade to DeployHub Pro.
{{% include "userguide/reusable/AuditTrail.md" %}}
The logic of an Action is defined using a graphical drag and drop blueprint designer. A tree view on the right shows all the Functions and Procedures organized by categories that can be include in the Action's logic. You can use the built-in activities for defining the logical steps of the Action or you can create new Procedures or Functions and have them available as activities to use. See Functions and Procedures for more information.
The blueprint designer contains all activities that make up the Actions logical processing steps, linked together in the order they are to be executed. Each step in the process has anchors where connections can be made. When you drag a item onto the designer, a blue input anchor is displayed at the top of the items "box." You will see a green anchor at the bottom representing output. In this way you can create connections between the processes.
Click on one of the Categories in the list to see the available Functions or Procedures. Expand a Category and then select the desired Activity to drag and drop it into the Action blueprint area. It appears as a box containing the name of the Function or Procedure. It automatically links to the nearest "box" with a output anchor.
The Parameter Dialog Box displays the options defined when the Function or Procedure was created using the Input Parameters Section from the Functions and Procedures Dashboard. When you add a new Function or Procedure to your Action blueprint designer, the Parameter Dialog Box will automatically display. If you are working on an existing Action and want to view the parameters, a right click will display:
- View Detials - opens the Parameter Dialog Box
- Got to the Procedure - takes you to the Dashboard of the Function or Procedure. Your work will be saved automatically before navigating to the Functions and Procedures Dashboard.
- Delete this Activity - deletes the Function or Procedure from the blueprint designer. An editor box opens automatically to set any input values required. If the dropped item is 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 items 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 items together and determines the order for processing the steps. The lines connecting items can be deleted by right clicking on the connector line and selecting "Delete this Connector".
Some Built-in Functions and Procedures have more than one exit point. For example the "if" process can be used to create conditional branches where different routes are taken through the logic 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.
Some Built-in Functions and Procedures can contain other Action's logic. When such Actions are dropped onto the blueprint area they are represented by a larger "box" containing a diagram showing the other Action. Double clicking on such an item will "drill down" into that item and open up another blueprint editor. Such Actions are typically "loops" (where the process "inside" the loop is executed for each iteration through the loop).
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 Procedures and Functions that simply wrap around DMScript (such as "Loop through Array Keys") that are not editable.
When the blueprint logic is executed, it's first converted into a DMScript Procedure. DMScript is DeployHub's built-in Object-Oriented Scripting Language.
{{% include "userguide/reusable/ListofActions.md" %}}