Using DeployHub with CI/CD
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:
|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: v18.104.22.168 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:
Below is a breakdown of the individual parts of the versioning schema:
|email-service||Base Name that you supply to the DeployHub Plugin for the Component.|
|ssl-update||Variant that you supply to the DeployHub Plugin for the Component.|
|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:
|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
<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:
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.
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.