DeployHub 101

Understanding Core Objects and Concepts.

Introduction

DeployHub’s core Objects are Domains, Applications, Components, Environments and Endpoints. These Objects catalog, track, and version independently deployable objects, maps their relationships, and releases them to clusters, cloud, or physical data centers.

Domains are core to DeployHub’s management of microservices. Domains are hierarchical and pass inheritance from parent to siblings. For this reason, Components can be shared across the Subdomains. The hierarchical structure of Domains provides a high-level of control and management over how microservices are shared and reused.

Example of Domains, Applications, Components and Environments

Other Objects include:

  • Change Request
  • Credentials
  • Data Sources
  • Date
  • DropZone
  • DropZone File
  • Notifiers
  • User
  • UserGroup (DeployHub Pro Object)

These Objects can be referenced using DeployHub APIs or custom DMSCripts.

Following is a description of each Object and their attributes.

Application Object

Applications are a collection of Components that can be deployed as a single software solution. You define an Application by associating the Components it will consume. The first version is the Application Base Version. When you change this Application Base Version, you create a new Application Version. Applications are assigned and deployed to Environments. Applications are associated to a Domain.

  • Application Base Version : Defines the software product in terms of Components, Attributes, and assigned Environments.

  • Application Version : This represents any changes made in to the Base Versions.

An Application has the following properties:

Property Description
id A unique identifier for the Application in the database.
name Application name.
fqdomain Fully qualified Domain name.
summary Summary of the Domain.
owner User or Group that owns it.
parent The Base Application.
predecessor Predecessor Application Version.
Release Defines the Application Object with more than one Application.
Applications Multiple Applications used to create a Release.
Components The objects that the Application consumes.
approvals Allows a control point for progressing a change within the pipeline process.
requests The Change Request objects associated with this Application.
creator The User or Group who created it.
modifier The User or Group who last modified it.
ctime The date/time it was created.
mtime The date/time it was last modified.
KV Configurations Key Value Pairs for managing associative arrays.

Release Object

A Release is only available in DeployHub Pro. A Release is a collection of Applications that must be deployed together, sometimes referred to as a ‘Release Train.’

Change Request Object

The Change Request Object represents a change request record associated with either a Component or an Application. A Change Request is a DeployHub Pro feature.

The Change Request object has the following properties:

Property Description
id The Change Request id.
name The Change Request description.
status The Change Request status.
api_url A URL which, if passed to restful_get, will return an array containing the full details of the Change Request from the external change tracking system. Useful for getting more information than the id / description / status combination which is stored in DeployHub.
html_url A URL which will direct a browser to the page describing the change request in the external change tracking system.

Component Object

DeployHub manages microservices and other reusable objects as Components. These are assigned to an Application even though they are managed independently. By assigning Components to Applications you track a ‘logical’ view of your software solution. In a monolithic approach, this happened at the software compile and link step. In microservices though, they are loosely coupled and linked at run-time. Defining Components to Applications puts the Application back in the picture, even if it is only a ‘logical’ view.

If you are an API or microservice developer, this will be where you do most of your work. However, application developers may also define Components for a specific Application. Components are microservices (containers), Database updates, or other deployable objects. By tracking the low level deployment metadata for a Component, it can be easily shared and released in a consistent way across team.

Components change over time, and so DeployHub contains Component Base Versions and Component Versions like those of Application Base Versions and Application Versions. And like Applications, Components are associated to a Domain.

  • Component Base Version : Objects within DeployHub that contain the files and procedures deployed to Endpoints.

  • Component Version : A child of the Component Base Version that represents changes.

A Component Object has the following properties:

Property Description
id A unique identifier for the Component as used in the database.
name The name of the Component.
fqdomain Fully qualified Domain name.
summary Description of the Component.
domain Domain in which the Component is contained.
owner User or UserGroup that owns the Component.
parent The Base Component.
predecessor The version on which this is based.
items The items that make up this Component.
servers The Endpoints to which this Component has been deployed.
requests The change requests associated with this Component .
lastbuild The last build number for this Component, 0 if never built.
creator The User who created this Component.
modifier The User who last modified this Component.
ctime The date/time the Component was created.
mtime The date/time the Component was last modified.
Key Value Configurations Key Value Pairs for managing associative arrays.

Component and Application Relationships

There is a many-to-many relationship between Applications and Components. An Application can contain many different Components, and a Component can be used across many different Applications. Components can be easily shared between Applications. DeployHub tracks and versions the Component relationships including to which Applications they have been assigned.

Component and Application Versioning

A backend versioning engine tracks all software deployment configurations. This is done within an Application. An Application consists of one or more Components. Versioning tracks all changes in both your Application and Component attributes. This includes all low level information such as the Action used to perform the installation, environment variables, and database schemas.

When you first define your Application, you create an Application Base Version. Over time, as you update your code and deliver new features, each change to the Application creates a new Application Version. Application Versions package all your Components in your entire software product. Like Application Versions, there is an initial Component Base Version and subsequent Component Versions, which represent any updates . An Application Base Version or Component Base Version is always the first one created, and it acts as a model for subsequent Application or Component Versions. Otherwise they are identical types of objects.

When a new Application Version is created from either an Application Base Version or another Application Version, it inherits all previous Components from its predecessor. That predecessor is determined when running a Create Version Task for an Application Version. You can specify whether the new Application Version inherits its Components from the original Application Base Version, the latest Application Version, or a specific Application Version.

DeployHub uses a simple versioning number schema starting at 1 and incrementing over time, for example Myapp;1, Myapp;2.

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

Credential Object

The Credential Object contains the logon and password needed to access EndPoints and external repositories like Git or Quay.

The Credential Object has the following properties:

Property Description
id A unique identifier for the Credential as used in the database.
name The name of the Credential.
summary Description.
fqdomain Fully qualified Domain name that the Credential is associated with.
domain Domain in which the Credential is associated.
owner User or Group that owns the Credential.
username Decrypted username.
password Decrypted password.
b64auth A string representing the decrypted username and password together, with a : separator and then base64 encoded. Used for Basic Authorization for web-based APIs.
creator The User or Group who created this Credential.
modifier The User or Group who last modified this Credential.
ctime The date/time the Credential was created.
mtime The date/time the Credential was last modified.
Type Credential use.

Data Source Objects

The Data Source object communicates with various sources of information such as databases, HTTP servers, FTP servers, etc., and can be used to connect to other DevOps tools as needed.

Date Object

Dates track the date/time of the creation, deletion, or update of an Object.

The Date has the following properties:

Property Description
to_int(secs) Returns an integer representing the date as the number of seconds since midnight on January 1st 1970 (epoch). The secs parameter is optional. If needed, the specified number of seconds is added to the date/time before the new value is returned.
to_char(fmt) Formats the date into a string given by the passed fmt string. The fmt string should contain characters as specified below.

Domain Object

The Domain Object represents the highest order of organization for managing Applications, Components and Environments. Domains are hierarchical and can have Subdomains. Subdomains inherit the parents properties, Tasks and access.

Your microservices, a type of Component, are cataloged based on Domains and Subdomains which you define. Domains catalog microservices that solve the same ‘problem sets.’ In a similar way, Applications are assigned to their own Domain. Environments and Endpoints are associated to Domains that are managing Applications.

The highest level Domain is your Global Domain. With the SaaS version, your Global Domain name is defined based on your Company. With the on-premise installation, you will see a Domain called Global.

Domains also include Tasks. Tasks include Move, Approve, Version and Deploy. Tasks can be called by external solutions via APIs for integration into your Continuous Delivery Pipeline. Tasks are associated to any Domain and can be defined as Pre or Post. Tasks are normally defined to Life Cycle Subdomains and support continuous configuration management in your continuous delivery process.

Life Cycle Subdomains allow you to automate the push of your continuous deployments from development through production. DeployHub can be called by your Continuous Delivery engine (Jenkins, Bamboo, GitLab, CircleCI, Puppet Relay, Google CloudBuild or GitHub Actions) to perform the continuous deployment task across all states of your pipeline. If you are not using a Continuous Delivery orchestration engine, you can assign Tasks to your Life Cycle Subdomain to define a continuous deployment ‘promotion’ process within DeployHub.

The following properties can be accessed on the Domain object:

Property Description
id Domain id, as used in the database.
name Domain name.
fqdomain Fully qualified Domain name.
summary Summary text.
domain Higher level Domain to which it belongs.
subdomains List of Domain objects which are contained within it.
Life Cycle A Domain that includes a pipeline and the lowest level Subdomains. Life Cycle-domains cannot have Subdomains.
Applications The Application objects which are contained within it.
Environments The Environment objects which are contained within it.
creator The User or Group Object representing the user who created it.
modifier The User or Group Object representing the user who last modified it.
ctime Date Object representing the date/time it was created.
mtime Date Object representing the date/time it was last modified.
owner User or Group Objects that owns it.

Dropzone Object

The DropZone Object represents a local area where deployment artifacts are manipulated before sent to the target Endpoints. A DropZone Object is also present on the stack during Pre and Post Action processing for a Component. For example, the content of the DropZone are the files checked out from the repository for the associated Component.

A DropZone Object has the following properties:

Property Description
name DropZone name.
path The full path of where the DropZone is located. Useful for passing to external scripts that may need to manipulate files in the DropZone.
files An Array of DropZone Objects, each one of which represents a file in the DropZone. The array is keyed by the full path name of the file.

DropZone File Object

The DropZone File Object represents a file in the DropZone.

The DropZone File Object has the following properties:

Property Description
dzpath The relative path of the file in the DropZone.
repopath The relative path of the file as located in the repository (this path is relative to the base directory of the repository).
size The size of the file in bytes.
ctime The creation time of the file.
mtime The modified time of the file.

Environment Object

The Environment Object represents a collection of Endpoints where an Application is deployed. Multiple Environments can represent your pipeline stages such as Development, Testing, and Production for a single Application. Your Application can have as many Envrionments as needed.

The following properties can be accessed for an Environment object:

Property Description
id Unique identifier as used in the database.
name Environment name.
fqdomain Fully qualified Domain name.
summary Description of the Environment.
domain Domain in which it is contained.
owner User or Group Objects that owns it.
basedir Base directory for deployments.
Endpoints The Endpoints assigned to it.
Applications The Applications associated to it.
creator The User or Group who created it.
modifier The User or Group who last modified it.
ctime The date/time it was created.
mtime The date/time it was last modified.
parent Parent Domain.

Endpoint Object

The Endpoint Object (Local Helm Host, container, VM/Cloud Image) represents where a deployment will be sent. Endpoints are assigned to an Environment.

Endpoint Mapping

Each Component is assigned a Type attribute. You can specify which kind of Endpoint is needed. For example, a Database Component is installed onto an Endpoint with a corresponding Database Type definition. A Component is assigned a single Type, while an Endpoint can be assigned multiple Types. For example, if your single Endpoint needed to have both a database and your application binaries installed, it would be assigned both a ‘Database’ and a ‘Binary’ Type attribute.

To map a Component to Endpoints, assign one or more Component Types to each Endpoint. Then assign a single Type attribute to that Component. When an Application is deployed, each Component within the Application will be deployed to each Endpoint if the Component’s Type attribute matches one of the Endpoint’s Type attributes. DeployHub ships with standard Component and Endpoint Types and allows you to define custom Type attributes.

The Endpoint object has the following properties:

Property Description
id A unique identifier as used in the database.
name The Endpoint name.
fqdomain Fully qualified Domain name.
summary Description of the Endpoint.
domain Domain in which it is contained.
owner User or Group that owns it.
hostname Hostname (if set) or name otherwise.
basedir Base Directory for Deployments.
type Endpoint Type, ie: cluster, windows, cloud, etc.
credential The logon and password used to access this Endpoint.
Components The Components currently installed on it.
creator The User or Group who created it.
modifier The User or Group who last modified it.
ctime The date/time it was created.
mtime The date/time it was last modified.
Key Value Configurations Key Value Pairs for managing associative arrays.

Notifier Objects

A Notifier is sent after a successful or failed deployment attempt. If these features are activated, they are also sent when deployed files have been changed, a Request Task has been used, or when an Endpoint is down, DeployHub can use SMTP (Simple Mail Transfer Protocol), Slack and HipChat for this purpose.

User Object

The User Object represents a User in DeployHub. It has the following properties:

Property Return Type Description
id Integer User id, as used in the database.
name String User Name.
kind String Returns “user”. Used to differentiate between users and groups when retrieving an owner object.
fqdomain String Fully qualified Domain name.
realname String The User’s full name.
email String The User’s email address.
phone String The User’s telephone number.
groups Array Array of Group Objects to which this User belongs.
lastlogin Date The date/time last logged into DeployHub.
creator User User or Group Object representing who created this User.
modifier User User or Group Object representing who last modified this User.
ctime Date Date Object representing the date/time the User was created.
mtime Date Date Object representing the date/time the User was last modified.
owner Object User or Group that owns the User

Group Object

The Group Object represents a collection of Users with the same Domain and security access. (This is a DeployHub Pro Feature.)

The Group Object has the following properties:

Property Description
id A unique identifier as used in the database.
name Group Name.
kind Identifies whether this is a User or a Group.
fqdomain Fully qualified Domain name.
email The Group’s email address.
creator User or Group Object representing who created this Group.
modifier User or Group Object representing who last modified this Group.
ctime Date Object representing the date/time it was created.
mtime Date Object representing the date/time it was last modified.
owner User or Group that owns the object.