Using DeployHub with CI/CD

Integrating DeployHub into your CI/CD process.

DeployHub’s Continuous Delivery Integration

The DeployHub continuous delivery integration is used to perform both continuous configuration management and continuous deployments across clusters, clouds and physical data centers. It does this by gathering configuration data related to a build, creating new Component Versions and Application Versions, and deploying independently deployable Components into specified Environments. It also saves the “build” data as part of the configuration information and associates it to the Component and Application.

DeployHub’s uses a standard CLI Container to integrate with continuous delivery solutions that execute workflows in containers. If the solution has a more traditional model, a plug-in is required. Following is a list CD tools that DeployHub has performed joint integrations and their corresponding documentation on how each should be implemented:

CI Tool DeployHub Plugin Reference Document
Jenkins DeployHub Groovy Library Jenkins CI Plug-in
CircleCI DeployHub CircleCI Orb DeployHub Orb
Google CloudBuild DeployHub CLI Container DeployHub CLI Docker Container
GitLab DeployHub CLI Container DeployHub CLI Docker Container
TeamCity DeployHub CLI Container DeployHub CLI Docker Container

Tracking Build Updates

DeployHub’s first hook into the continuous delivery process occurs after the build has been completed and the container has been pushed to a container registry. DeployHub can support any container registry. For more details, reference the above table for for each supported solution.

Saved Build Data

Build data is saved to the Component Version and displayed on the Component Version Dashboard. In some cases, DeployHub may need to save custom data. This can be done using the Component Attributes and saved as a key/value pair. This custom data is then displayed as Attributes to the Component Version in the Attributes Section.

The Component Type determines what data is saved. See Defining Components for a complete listing of the Detail data saved for each different Component Type.

Continuous Configuration Management and Versioning

Continuous configuration management and versioning is the process of creating new Application Versions based on the detection of build updates. When an update is detected, DeployHub becomes aware of a new Component Version in the continuous delivery workflow. This tells DeployHub that a new Component Version is available, triggering DeployHub to update the dependency relationship maps of all the consuming Applications, therefore creating new Application Versions.

This continuous configuration step is particularly important in a microservice implementation. Every time a new microservice is pushed across the pipeline, it impacts the configuration of the “logical” Application that consumes it. A new microservice Component creates a new Application Version. This is how DeployHub presents the Application Version Dashboard data showing the relationship and difference maps for each cluster to which the microservice Component is deployed.

Component Versioning Schema

DeployHub versions Components differently than it does new Application Versions. Components are tied to Git commits, Applications are not.

The following are the parts of the versioning schema:

Schema Description
Base name is the static part of the Component Name. For example: email-service.
Variant is a high level place holder for the versions are created within. The Variant can be aligned with a feature or branch. For example: ssl-update. Variant is not required.
Version is the schematic version number or schematic + Git commit. For example: v1.5.1.0 or v1.5.1-g3d55a2

By default, DeployHub uses an advanced format for the versioning schema. It will automatically increment the version number based on last version found. The advanced format is used since DeployHub has the information from Git to provide a complete version schema. The advanced formatting is:

 <base name>;<variant>;v<version>-g<git commit>

The version segment is broken down further into:

 v<schematic number>-<number of commits>

The number of commits provides an auto-increment of the last part of the schema number.

An example of the full name is:

 email-service;ssl-update;v1_5_1_145-g3d55a2

Below is a breakdown of the individual parts of the versioning schema:

Part Explanation
email-service Base Name that you supply to the DeployHub Plugin for the Component.
semi colon Separator.
ssl-update Variant that you supply to the DeployHub Plugin for the Component.
semi colon Separator.
v Indicates start of the version.
1_5_1 Version that you supply to the DeployHub Plugin for the Component.
145 Number of Git Commits for the associated repository. Used for auto incrementing.
-g Separator indicating that the Git commit is next.
3d55a2 Git command SHA for the commit that triggered the CD process.

Note: The Variant is optional. That part of the Component name will be left out if the Variant passed to DeployHub by the CD workflow is blank.

Application Versioning Schema

The DeployHub continuous delivery integration will automatically maintain the Application Version if the Application Name and a starting version identifer are provided. If the Application Name and version identifier are passed to DeployHub a new Application Version will be created using the previous version identifier as a starting point. An Application Base version must exist in order for DeployHub to automatically create a new Application Version when a new Component Version is created. The base version gives DeployHub the starting point to perform automatic Application versioning.

DeployHub uses a similar naming convention for Application Versions as it does for Component Versions:

Part Explanation
Base name The static part of the Application Name. For example: webstore.
Variant A high level place holder for that versions are created within. The Variant can be aligned with a feature or branch. For example: 50percent-sale. Variant is not required.
Version The schematic version number. For example, 1_2_10.

DeployHub uses the ;; as the default format for the versioning schema. The formatting is:

<base name>;<variant>;<schematic version number>;<version number> if a Variant is used. 

Deploy will automatically increment the version number based on last version found. It will create a new Application Version based on the last Application Version and replace the old Component Version with the new Component Version. The new Component Version will be added if an old verion was not found.

You can use your CI/CD process to include variance in your versioning number (base name, variant, version). See Component Versioning Schema.

Deploying the Application Version

Once the versioning is completed, DeployHub is called to perform the deployment. The Application Version and Environment are required for the deployment. The deployment number will be returned to both DeployHub and the continuous delivery solution to be displayed in the output.

Life Cycle Tasks and Continuous Delivery Workflows

You can incorporate DeployHub’s Life Cycle Subdomain Tasks as follows:

Move

DeployHub will move the Application from one Life Cycle Subdomain to another using the DeployHub Move Task. This enables the Application to move through the same pipeline steps that the CD process is using.

Approve

If you are using DeployHub Pro, you can incorporate Approvals into your process. DeployHub will perform an Approval of an Application Move. This Approve feature is used to reflect an approval that was done in the CD Pipeline for an Application’s audit trail.

For documentation on incorporating Tasks, refer to your specific CD tool documentation as listed above.

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