Executing Deployments

The DeployHub Deployment Engine and Incremental Processing

DeployHub uses a deployment engine to perform the push of deployments across your Environments. For SaaS users, your reverse proxy is your deployment engine. For on premise installations, your deployment engine is installed as part of your DeployHub installation. The deployment engine is called when a deployment is initiated. The job of the deployment engine is to do the decision making about what Components need to be released, and what processing logic is required. Deployment processing is based on the deployment configuration of the Component. DeployHub deploys Applications which are a collection of Components, on an increment basis. If a Component is already running in an Environment, it is not re-released. This is how DeployHub independently deploys microservices, and handles roll forward or rollback logic. DeployHub uses a backend version control engine to achieve incremental deployments, forward or backward.

Roll Forward or Rollback

Whenever a deployment has a problem, DeployHub can provide a fast and safe repair with Roll Forward and Rollback of an Application using Components. Roll Forward or Rollback allows DeployHub to apply Components to Endpoints incrementally and in order. As DeployHub interrogates its versioning engine for each Application Version, the associated Components are advanced to a new version, or replaced with a previous version to handle the Roll Forward or Rollback conditions.

Configuring Deployment Logic

DeployHub uses either the default Action or Custom Actions (i.e., Helm, Ansible, external script) to handle the deployment processing of your Application and Components. For most deployments, no customization is required and is easily supported with the default Actions. When a Custom Action is used, it relys on an external process to manage the deployment processing.

Executing Deployments with the Default Actions

When you execute a deployment, DeployHub will call a default Action to push the Component from the source location to the target Endpoint. You can customize the deployment process by writing your own Actions that allow you to refine the way the deployment processing 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 to which they belong. For most users, no modifications to the default Actions are required. For your microservice Components you will use a Custom Action that calls your Helm chart.

Executing Deployments with Custom Actions

Custom Actions allow you to execute existing one-off deployment scripts and can support an easy transition to using DeployHub. You can choose to bypass DeployHub’s default Actions using a pre-defined our newly created Custom Action. This can be used to call other tools such as Helm, Ansible or a homegrown deploy script that does the heavy lifting of managing deployment logic. To use a Custom Action you will define your Component with the Custom Action that will take over the normal deployment processing. When a Custom Action is designated within an Application or Component, any default Pre or Post Action is ignored and not executed during the deployment. If a Custom Action is used, it can use one or more DeployHub Procedures, Functions, and Actions, in a predetermined order.

Distributed Deployments for Traditional Data Centers

For large distributed traditional data centers you can install multiple deployment engines and assign them to specific Project Domains to handle large ‘fan out’ deployment processing. Multiple deployment engines can be used to distribute the deployment processing for large data centers with thousands of physical Endpoints, but is not required for a modern Kubernetes architecture. You can change the deployment engine at the Domain Details section using the Engine Hostname Detail field. This field tells DeployHub which engine to use for deployments in that Domain. If you need to implement multiple deployment engines for large distributed deployments, contact our Support Team. They can provide you a link to download an installer that includes only the deployment engine and not the full DeployHub install. You would use this installer to build out separate deployment engines that are then defined to the Domain allowing each Application to have its own engine.

Executing Deployments

Deployments can be executed:

• On Demand
• With Roll Forward or Rollback
• Scheduled via the Calendar
• Automated from Continuous Delivery

Executing Deployments On-demand

An on-demand deployment can be initiated for an Application or Release using a Deploy Task. Once the Deploy Task has been defined in the Domain, it will be available from the Application List View. By selecting the Application Version and going to the Task drop down, you can push a deployment on-demand.

Roll Forward Incremental Deployments

You execute a roll forward or rollback deployment on-demand. To roll forward or rollback, go to the Application List View, select the new or older Application Version you wish to deploy and use the Deploy Task available from the Task Tab. This will push the selected version to the cluster incrementally.

DeployHub and Your Continuous Delivery (CD) Pipeline

DeployHub is added to your CD pipeline to perform continuous configuration management of your Applications and Components, and to push them to runtime Environments across your defined Life Cycle.

DeployHub uses a built-in deployment pipeline for tracking an Application’s journey across a software delivery Life Cycle, i.e. Dev, Test, Production. However, it is important to understand that a DeployHub Life Cycle Subdomain is not intended to replace your CD orchestration solution. DeployHub integrates with your CD pipeline becoming a part of your overall ecosystem for versioning, tracking and deploying software to clusters, cloud environments and physical data centers.

DeployHub tracks an Application’s configuration including where it is in the Life Cycle in terms of Environments. An Environment is assigned to a Life Cycle Subdomain. Therefore, DeployHub can track where a Component or Application is in the Life Cycle based on where it has been installed. Each Life Cycle Subdomain can contain multiple Environments. Regardless of what Environment an Application is running in, DeployHub can still track where it is in the Life Cycle process based on the Life Cycle Subdomain. This is the core function of Life Cycle Subdomains.

A Life Cycle Subdomain is the lowest level Domain. You can not create a Subdomain off of a Life Cycle Subdomain.

Using a Life Cycle Subdomain

When you create a Life Cycle Subdomain, you provide a means to include Life Cycle state information as part of your Application’s configuration. For each state of your software delivery Life Cycle, you create an associated Life Cycle Subdomain for your Application. You do this by using the Domain Dashboard. Navigate to your Application’s Domain, select the “All Subdomains are Life Cycles” checkbox, and then add your child Subdomains. All Subdomains will represent your Life Cycle process. You will need to navigate to the Environment Dashboard to add the Environments to your Life Cycle Subdomains.

Establishing the Progression Order of Your Life Cycle

You can force the progression of your Life Cycle process by adding a “Move” Task to the Life Cycle Subdomain. At the “Move” Task level, you define what Life Cycle Subdomain will be the next state (the “move to Domain). This is how DeployHub clearly defines the order of how an Application should progress through the Life Cycle, i.e. first development, then test, and finally production. A “Move” Task does not perform a deployment, it just stages the Application for a deployment into the Environments associated with that Life Cycle Subdomain.

To deploy an Application into an Environment make sure that the Deploy Task is assigned to the Domain. The Deploy Task is the default Task for all newly created Domains.

Your Life Cycle Subdomains and your Continuous Delivery Engine

Your continuous delivery (CD) engine will define your Life Cycle progression. When you integrate DeployHub into your existing CD Pipeline, you will need to define your Life Cycle Subdomains to mimic your CD Workflow progression. You can then associate integration of each of your CD Workflows directly to a DeployHub Life Cycle Subdomain. You can perform calls to DeployHub to both “Move” and “Deploy” Applications into Environments. If you are a DeployHub Pro users, you can also call “Request” and “Approve” Tasks as part of your integration. These Tasks interact with DeployHub Pro “Smart” calendars, not available in DeployHub Team. See Using DeployHub with CI/CD for more information on connecting your CI/CD solution to DeployHub.

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 Environment’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.