Deployment Tasks

Task are used for executing deployments, managing approvals, or staging a deployment. Tasks can be assigned to any Domain. However, they are most commonly associated to Project Domains and Life Cycle Domains. You can assign a Task at a higher Domain level allowing any child Domains to automatically inherit the Tasks. This inheritance simplifies managing Tasks by making some common to all of your Subdomains. However, this means that a Catalog Domain may include Tasks that it cannot use.

The following Tasks are available as default Tasks, but you can create any type of custom Task. A custom Task will call a Custom Action:

  • Move Version to the Next or Previous Pipeline State
  • Deploy Version to Environment
  • Manually Trigger Action to be executed

DeployHub Pro:

DeployHub Pro includes a “smart” Calendar. The following Task are used to interact with the DeployHub Smart Calendar for Requesting and Approving deployments.

  • Request Calendar Entry for Deployment to an Environment
  • Approve Version for Move to Next Pipeline State

Adding, Editing and Deleting Tasks

You can add new Tasks from the Domain Dashboard by navigating to the Domain and interacting with the Tasks Section. Select the +Add option from the Tasks Section and a pop-up displays all available Tasks. Selecting a Task will add a new row into the table. Use the Task Detail Section to define the unique details of your new Task. You can update or remove a Task by using the Task Section table. Using the checkbox, select the item and use the the Delete or Edit options.

Once you create a Task, it is recommended that you rename that Task to more closely describe its use depending on the options selected.

Below is a description of all Tasks and their detailed information.

Move Version to the Next or Previous Pipeline State

Moves an Application or Release version from one Pipeline state (Life Cycle Subdomain) to another. This can be used as a promotion or a demotion of an Application or Release version between Life Cycle states. When the Task is defined, the Life Cycle Subdomain has to be specified as part of the Task definition. The Approval Task must be accepted before the Move Version is to succeed.

“Move” Task Detail Fields Description
Name The unique name of the Task.
Created Auto-generated date and time the Task was added.
Modified Auto-generated date and time the Task was updated.
Pre-Action Change the default behavior by assigning a custom Action to execute as a Pre-processing step.
Post-Action Change the default behavior by assigning a custom Action to execute as a Post-processing step.
Available in Subdomains Once selected, all Subdomains will have access to this Task.
Move To Domain The target Domain where the version will be moved.
Success Notify Template The Notify Template emailed on a successful move. You need to define the Notify Template from the Setup Menu. See more on Notify Templates.
Failure Notify Template The Notify Template emailed on a failed move. You need to define the Notify Template from the Setup Menu. See more on Notify Templates.

Deploy Version to Environment

Deploys an Application or Release version to an Environment. Select the target Environment via a drop-down list.

“Deploy” Task Detail Fields Description
Name The unique name of the Task.
Created Auto-generated date and time when added.
Modified Auto-generated date and time when updated.
Pre-Action Change the default behavior by assigning a custom Action to execute as a Pre-processing step.
Post-Action Change the default behavior by assigning a custom Action to execute as a Post-processing step.
Available in Subdomains If selected, all Subdomains will have access to this Task.

Manually Trigger Action to be executed

Runs a stand-alone Action. For example, if you need to interrupt a deployment process, this Task allows you to execute the steps manually. The manually triggered Action will be placed in the “To do” list of the User or Group that executed the Deploy Task.

“Manually Trigger” Task Detail Fields Description
Name The name of the Task - can be changed to make the Task unique.
Created The auto generated date and time the Task was added.
Modified The auto generated date and time the Task was updated.
Pre-Action You can change the default behavior by assigning a custom Action to execute as a Pre-processing step.
Post-Action You can change the default behavior by assigning a custom Action to execute as a Post-processing step.
Action to Run The Action that will be executed manually.
Available in Subdomains If selected, all Subdomains will have access to this Task.
Success Notify Template The Notify Template that will be emailed on a successful Action. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.
Failure Notify Template The Notify Template that will be emailed on a failed Action. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.

Approve Version for Move to Next Pipeline State

Approves the Application or Release version so that it can be moved to a specified state in the pipeline (Life Cycle Subdomain). This works in conjunction with the Move Version Task. When the Approve Task is defined, the Target Domain has to be specified. When the Approve Task is executed, the selected Application or Release version can either be Approved or Rejected. Only when the an Application or Release version is “approved” can it be “Moved” or “Deployed”.

Note: When an Approve Task has been defined for a Domain, it will force the use of the Approve Task before a “Move” or “Deploy” Task can be executed. If a “Move” or “Deploy” Task is attempted but has not been “Approved,” an error will be displayed indicating that the Task must be Approved.

“Approve” Task Detail Fields Description
Name The name of the Task - this information can be changed to make the Task unique.
Created The auto generated date and time the Task was added.
Modified The auto generated date and time the Task was updated.
Pre-Action You can change the default behavior of this Task by assigning a custom Action to execute as a Pre-processing step.
Post-Action You can change the default behavior of this Task by assigning a custom Action to execute as a Post-processing step.
Available in Subdomains If this is selected, all Subdomains will have access to this Task.
Approval Domains The target Domain that approval is the subject of.
Approval Notify Template The Notify Template that will be emailed on approval. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.
Rejected Notify Template The Notify Template that will be emailed on rejection. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.

Request Calendar Entry for Deployment to an Environment

DeployHub Pro feature. Sends a request from a User to add a time slot to the calendar for a deployment. The request is sent to Group who has the authority to manage a particular Enviornment’s Calendar. When the Request Task is defined it is linked to the task to be requested. When the Request Task is executed an entry is placed into the “To Do” list of all the Users who are members of the Group with the calendar access. The Request Task can have a Request Notification Template defined which can send out a notification to the appropriate Groups.

“Request” Task Detail Fields Description
Name The name of the Task - can be changed to make the Task unique.
Created The auto generated date and time the Task was added.
Modified The auto generated date and time the Task was updated.
Pre-Action You can change the default behavior by assigning a custom Action to execute a Pre-processing step.
Post-Action You can change the default behavior by assigning a custom Action to execute a Post-processing step.
Available in Subdomains If selected, all Subdomains will have access to this Task.
Linked Task The target Domain where the version will be moved.
Request Notify Template The Notify Template emailed for the request. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.

Task Execute Access

Once a Task is defined, it must be granted execute access to a Group before it can be invoked. Select the Task using the check box. Drag the desired Group from the Available Groups column to the Group Access area. Users of the Group can then execute the specified task.

Groups are assigned authority on a Task by Task basis. It is possible for a Domain to have two different Tasks with the same function, one of which allows a particular Group to run the Task, and the other which doesn’t. This allows similar Tasks to be created. They can have different characteristics assigned to them such as Pre-Actions and/or Post-Actions, Notification Templates, etc. Also different User Groups can have the authority to run them.

  • Example: A Group can run a “Move” Task, sending an Application Version from the Test Life Cycle State to the Production Life Cycle State. A Group consisting of testers perhaps does not have the ability to run that same Task.

  • Example: A Move Task is linked to a Request Task. A User in the Test Group would run the Request Task, which notifies Users in the Release Group and requests that the Application Version be moved. Users in the Production Group would then receive the Request Task through their To Do List and optionally an email (which was designated as the Request Notification Template in the Request Task). They would then run the linked Move Task to move the Application Version to the Production Life Cycle State.

NOTE: Another way to accomplish this is to link an Approval Task to the Request Task. The User in the User Group would send the Request Task, and a User in the Admin Group would be notified. They would then run the Approve Task to allow the User in the Test Group to run the Move Task.

Additional Task Parameters

Additional parameters can be added to a Task. These additional parameters will set Global Variable at execution time. To add them, select the Task from the Task Section. Use +Add to create a new entry into the Parameters table for the selected task. It will have two columns:

  • Label: This will appear on the Task’s execution window whenever the Task is executed.

  • Variable: An Entry, Password, or Dropdown field appears to the right of the Label whenever a Task is executed, where values can be either entered or selected, depending on the Type.

Use the Save to commit the change to the table. Use Edit to update a Task Parameter, or Delete to remove a Task Parameter.

Last modified July 9, 2020: small cleanup (b45ee8f)