Executing Deployments

The DeployHub Pro Deployment Engine and Incremental Processing

DeployHub Pro 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 Pro 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 Pro 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 Pro independently deploys microservices, and handles roll forward or rollback logic. DeployHub Pro uses a backend version control engine to achieve incremental deployments, forward or backward.

Roll Forward or Rollback

Whenever a deployment has a problem, DeployHub Pro can provide a fast and safe repair with Roll Forward and Rollback of an Application using Components. Roll Forward or Rollback allows DeployHub Pro to apply Components to Endpoints incrementally and in order. As DeployHub Pro 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 Pro 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 Pro 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 Pro. You can choose to bypass DeployHub Pro’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 Pro 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 Pro 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 Pro 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 Pro and Your Continuous Delivery (CD) Pipeline

DeployHub Pro 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 pipeline. Learn more by reading the CI/CD Chapter