DeployHub includes a central engine that can be installed locally or from the SaaS offering via a reverse proxy. The central engine connects to external repositories, Continuous Delivery (CD) engines, DevOps tools, data sources, transfer protocols and notification tools. With our open architecture, you plug-in the tool-set you use to define your release configurations.
For releasing Components, an agentless architecture supports both a modern architecture of containers as well as legacy systems. If you use solutions like Helm or Ansible to update your cluster, great, we can call those external solutions to perform the updates and provide all the microservice configuration mapping and version information. DeployHub also has plug-ins to continuous delivery pipelines that supports continuous configuration management as part of your release process.
Reverse Proxy and SaaS
As a SaaS customer, a ‘one-way’ reverse proxy is used on your side of the firewall. The proxy send requests for deployments every 60 seconds.
Deployments with Custom Actions for Cloud Native Releases
DeployHub integrates with external deployment solutions such as Helm to perform the actual movement of containers to a cluster. When a Custom Action is used, the internal deployment engine is bypassed. This is the easiest way to perform an update to your cluster.
The DeployHub Engine for Monolithic Releases and Database Updates
Our deployment engine manages monolithic deployments and database updates. It moves files and scripts from source Repositories to a target Environment which contains one or more Endpoints. This is performed via Releases or Applications, which contain Components. Components reference a Repository, whose files and scripts are placed into the Dropzone. Customized Actions manipulate the files (edit, delete, etc.) within the Dropzone. This happens before being deployed in a predetermined order to every Endpoint within the Environment.
DeployHub performs all deployments in an Agentless mode. No remote agents need be installed on the target Endpoint to execute deployments.
A DropZone is created for each Component during a deployment. Files from the Component are placed into the DropZone. After the Component has been processed, the files within the DropZone are deployed to the Endpoints within the selected Environment. The DropZone is then deleted. Another DropZone is created for the next Component, until all Components have been deployed for the Application. The next Application version is deployed, and the process starts all over again.
DeployHub uses ftp, ftps, sftp, or Windows protocol to transfer files. When a deployment is executed, DeployHub performs the following steps:
The first Application is moved onto the stack. Any Pre-Action for the Application will be executed at this point.
|1||The first Component is moved onto the stack.|
|2||A DropZone is created for the Component.|
|3||The first Component is processed. It references specific files from the Repository and these are placed into the DropZone.|
|4||If needed, A Pre Action for the Component is performed within the DropZone before deployment.|
|5||The DropZone files are placed into every Endpoint within the Environment where the Endpoint type is the same as the Component type. Keep in mind that a Component can have only one type and an Endpoint can have many types.|
|6||A Post-Action for the Component is performed for cleanup or additional manipulation of files. It is run against every Endpoint with the same Component Type as the Component.|
|7||If there are more Components, steps 2 through 7 are performed again after a new DropZone is created.|
|8||Pre and Post processing Actions defined in the Application or Release are performed on each of the target Endpoints in the Environments. Any errors found at the delivery level are logged and may fail the deployment. All logs are reported back to DeployHub and recorded in the Logs section for each Application or Release.|
The following diagram shows how the deployment process works: