Defining Components

How to Publish Components to Domains

Component List View allows Adding or Deleting

Use the Component List View accessible from the left hand Component menu option to manage your Components Base Version and Component Versions. Because each Environment has a row where the Component Base Version or Component Version has been deployed, there can be multiple entries for the same Component if it has been deployed to multiple Environments. A list of all Components is organized by the following:

List Column Description
Version The Component Base Version or Component Version number.
Domain The Domain to which the Component belongs.
Parent The Component Base Version from which the Component Version was created. This will be empty for the Component Base Version.
Environment The Environment to which the Component has been deployed. Each Environment will represent a different row in the List View table.
Last Deployment to Environment The Deployment Log number.
Completed The date and time of the last deployment to the listed Environment.
Results Success or Fail.

Note: If you have not defined any Components to DeployHub, you will see only the sample data.

You can also use the Filter bar, represented by a funnel icon, to reorder your Component List View:

  • Domain
  • Environment
  • Last Deployment
  • Parent
  • Result
  • Version

Additional Tabs from the Component List View

Tab Description
Refresh Refreshes the browser.
+Add Base Allows you to Add a new Component Base Version. You will select from one of three types: Container, Application File, Database
+Add Version Creates a copy of the selected Component.
Delete Deletes the selected item. However, you must delete the Components starting from the newest to the oldest. The Component Base Version would be deleted last. Sorting by “Version” gives you the order.
List Return to List View if in the Map View.
Map Displays a global Map of all Component versions, with their Application relationships.

Component Types

When adding new Components select the Component Type from the drop down list/:

Type Description
Container For Containers such as Docker.
Application File For binary files such as .jar, .war, .ear, .exe, .dll, Linux executable files, Oracle Forms, or similar artifacts.
Database For SQL files such as .ddl or other database update scripts.

How to View and Edit Components

Components are defined as Container, Application File, or Database. These are the different types of Components you may need from microservices to binaries and DB updates. The Dashboard view displays all information related to a specific Component Base Version or Component Version. Depending on what type of Component you are defining, you will be presented with different data definition fields.

The following fields are common to all Components:

Field Description
Full Domain The fully qualified path of the Domain that the Component is to be associated, showing all parent Domains.
Name The name of the Component.
Owner Type Owned by a User or Group.
Owner The owner of the Component, whose default value is the creator of the Component.
Summary A short text field with a description of the Component.
Created The date and time that the Component was created.
Modified The date and time of the last change.
Object Displays Component for the Base Version or Component Version.
Type The kind of Component created, i..e. Container, Application File, or Database.
Endpoint Type Used to map the Component to Endpoints within an Environment at deployment. This allows DeployHub to map the Component to the correct Endpoint when moving across different environments. You can add your own Endpoint Types from the Customize Types menu or select from the default options.
Change Request Data Source This Data Source is assigned to the Component for tracking Change Request. A Change Request Data Source must be pre-defined for this field to be used.
Category Assigning a Category to an Object allows lists of Objects based on Categories to be used throughout DeployHub. Add a new Category in the entry field or use an existing Category displayed in the drop down. Categories are most commonly associated with Actions, Functions and Procedures. Pre-defined Categories include:
  • Build - Actions, Functions and Procedures for calling ANT (SalesForce integration).
  • Database - Actions, Functions and Procedures for database updates.
  • Deploy- Actions, Functions and Procedures for Deployments.
  • Dropzone- Actions, Functions and Procedures for interacting with the Dropzone.
  • File Logic- Actions, Functions and Procedures related to File manipulation.
  • Flow Logic- Actions, Functions and Procedures for if then else in DMScript.
  • Loops- Actions, Functions and Procedures for file looping.
  • General-Non-categorized Objects (default).
  • WebLogic- Actions, Functions and Procedures for deploying to WebLogic.
  • WebSphere- Actions, Functions and Procedures for deploying to WebSphere.
  • Windows- Actions, Functions and Procedures used for Windows deployments.
  • Always Deploy The Component is deployed to the associated Endpoints in the Target Environment regardless if the Component is already present on the Endpoints. This is useful for monolithic applications where you want to copy over a binary for example.
    Deploy Sequentially Normally when a Component in an Application is deployed to several Endpoints in an Environment, it is deployed to each Endpoint at the same time (in parallel). The “Deploy Sequentially” option changes this behavior to force the Component to deploy to each Endpoint in turn, sequentially.
    Custom Action An Action that replaces the usual Deployment Engine processing. Custom Actions can be used to call Ansible, Helm or other external deployment tools.

    Container Specific Data Definition

    Helm is required for deploying Container Components. DeployHub interfaces with Helm to support a Kubernetes Cluster deployment.

    Initially, you will need to create a Custom Action for using Helm as your deployment engine. Once your Custom Action has been created, it can be reused by all Users as long as you define the Custom Action to your “Global” Domain. Follow the steps at Helm for Container Deployments.

    A Container Component has the following optional attributes:

    Field Description
    Build Job The Continuous Delivery Build Job that is used to build/compile the Component.
    Last Build Number The number of the last Continuous Delivery (CD) Workflow that created the files referenced within the Component. This number will default to the Build ID if one is not set by the CD Workflow.
    Build ID The internal identifier for the Build Engine.
    Build URL The URL to the Build Engine.
    Build Date The timestamp from when the last build job was run.
    Helm Chart The Helm Chart used to deploy the Component.
    Helm Chart Version The Helm Chart Version from the Helm Repository.
    Helm Chart Namespace The sub-division of the Kubernetes cluster where your Component Container should run.
    Operator The RedHat Operator used to deploy your Component container.
    Container Registry The Container registry where the Container is stored.
    Container Digest The SHA number of the Container image.
    Container Tag The tag that was assigned to the Container image.
    Git Commit The Git SHA number. Populated when integrated into Continuous Delivery Pipelines.
    Git Repo The Git Repository that triggered the build.Populated when integrated into Continuous Delivery Pipelines.
    Git Tag The last tag for the Git Repository. Populated when integrated into Continuous Delivery Pipelines.
    Git URL The URL for the Git Repository.Populated when integrated into Continuous Delivery Pipelines.

    Application Specific Data Definition

    Field Description
    Base Directory Base, or high level, directory where the file will be deployed. This value will be ignored if the Endpoint has a Base Directory defined. See Formatting Directories on the order of how the deployment directory is formatted.
    Target Directory The directory under the Base Directory where the file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
    Pre-Action An Action that is to be run prior to the deployment of this Component. This can be used to perform prerequisite requirements, such as creating directories, creating files from scratch, or moving files between directories.
    Post-Action An Action that is to be run after the deployment of this Component. This can be used to execute actions on the target Endpoint after the Component has been deployed.
    Build Job The Continuous Delivery Build Job that is used to build/compile the Component.
    Last Build Number The number of the last Continuous Delivery (CD) Workflow that created the files referenced within the Component. This number will default to the Build ID if one is not set by the CD Workflow.
    Build ID The internal identifier for the Build Engine.
    Build URL The URL to the Build Engine.
    Build Date The timestamp from when the last build job was run.
    Repository Choose the Repository that contains your Application binaries, files, etc. This list box is populated based on the Repositories pre-defined in your initial setup. Based on the Repository you select, you may be provided override or append fields if they were made available. For a list of the Repositories See Connecting Your Repositories for more information.
    • Filepath Override: Enter a filepath that will override the default filepath defined at the Repository level.
    • Pattern Override: Enter a pattern that will override the default pattern defined at the Repostory level. Patterns are file types you want to pull from the Repository, such as *.exe, *.dll, *.war.
    • Recursive Override: Select the box in order to override the default recursive behavior defined at the Repository level. This will turn recursion on or off depending on the setting at the Repository level.
    • Version Override: Overrides the default template of your versioning pattern defined at the Repository level.

    Database Specific Data Definition

    Database Components are used for making database updates such as table changes using SQL Scripts. Note: An database form (such as an Oracle Form) can be compiled and should be defined as an Application File not Database Component.

    Field Description
    Base Directory Base, or high level, directory where the file will be deployed. This value will be ignored if the Endpoint has a Base Directory defined. See Formatting Directories on the order of how the deployment directory is formatted.
    Pre-Action An Action that is to be run prior to the deployment of this Component. This can be used to perform prerequisite requirements, such as creating directories, creating files from scratch, or moving files between directories.
    Post-Action An Action that is to be run after the deployment of this Component. This can be used to execute actions on the target Endpoint after the Component has been deployed.
    Roll Forward Target Directory The directory under the Base Directory where the Roll Forward file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
    Roll Forward Repository Choose the Repository that contains your Roll Forward SQL. This list box is populated based on the Repositories pre-defined in your initial setup. Based on the Repository you select, you may be provided override or append fields if they were made available. For more information on Repositories see Connecting Your Repositories.
    • Filepath Override: Enter a filepath that will override the default filepath defined at the Repository level.
    • Pattern Override: Enter a pattern that will override the default pattern defined at the Repository level. Patterns are file types you want to pull from the Repository, such as *.exe, *.dll, *.war.
    • Recursive Override: Select the box in order to override the default recursive behavior defined at the Repository level. This will turn recursion on or off depending on the setting at the Repository level.
    • Version Override: Overrides the default template of your versioning pattern defined at the Repository level.
    Rollback Target Directory The directory under the Base Directory where the Rollback file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
    Rollback Repository Choose the Repository that contains your Roll Forward SQL. This list box is populated based on the Repositories pre-defined in your initial setup. Based on the Repository you select, you may be provided override or append fields if they were made available. For more information on Repositories see Connecting Your Repositories.
    • Filepath Override: Enter a filepath that will override the default filepath defined at the Repository level.
    • Pattern Override: Enter a pattern that will override the default pattern defined at the Repository level. Patterns are file types you want to pull from the Repository, such as *.exe, *.dll, *.war.
    • Recursive Override: Select the box in order to override the default recursive behavior defined at the Repository level. This will turn recursion on or off depending on the setting at the Repository level.
    • Version Override: Overrides the default template of your versioning pattern defined at the Repository level.

    Formatting of the Deployment Directory with Base and Target Directories for Database and Application File Deployments

    You must define the directory where your Component file is going to be deployed on your Endpoint. This is the purpose of your Component Base and Target Directories. The Base Directory is the high level directory, the Target Directory is the lower level, or final “Target” directory. Endpoints may be managed by a System Administrator who may want to force the use of a particular Base Directory on the Endpoint. If so, this directory can be set at the Endpoint Base Directory and override the Component level Base Directory. When a deployment occurs, the process will check to see if the Endpoint has a Base Directory defined, and will replace the Component Base Directory with the Endpoint Base Directory to create the full path for the deployment.

    Below is how the full file deployment path is formatted:

    Component Base Directory Value Component Target Directory Value Endpoint Base Directory Value Result
    Has Value Null Null The files will be placed in the Component Base Directory.
    Null Has Value Null The files will be placed in the Component Target Directory.
    Null Null Has Value The files will be placed in the Endpoint Base Directory.
    Null Has Value Has Value The files will be placed in the Endpoint Base Directory + Component Target Directory.
    Has Value Null Has Value The files will be placed in the Endpoint Base Directory.
    Has Value Has Value Null The files will be placed in the Component Base Directory + Component Target Directory.
    Has Value Has Value Has Value Endpoint Base Directory + Component Target Directory.
    Null Null Null Deployment will fail.

    Component Dependency Map

    The Dependency Map provides a graphical view of all Applications that is consuming this Component. This will remain empty until your Component is used by an an Application.

    Endpoints

    This section lists all Endpoints that the Component has been installed to with its Deployment Number. The Deployment Number is generated by DeployHub for each unique deployment. You can also use this section to stop incremental deployments and force a specific version to be deployed to the Endpoint. By manually adding a specific Component Version to the Endpoint, you bypass the incremental deployment logic of the deployment engine. For example, if you would like to deploy a particular container without accepting any intermediate updates, you would go to the intermediate Component Versions and manually add them to the Endpoints, causing the deployment engine to believe that it was previously deployed. When you manually add an Endpoint, the Deployment Number will show “manually deployed.” To manually add a Component to an Endpoint, use the +Add option. You will be provided a list of available Endpoints. Use Save to commit the change to the table. You can select multiple Endpoints. To Edit or Delete an Endpoint, select the Endpoint and use the Edit or Delete option.

    Key Value Configurations

    Key Value Configurations are Value Pairs for managing associative arrays assigned to the Object.

    Key Value Pairs can be assigned at multiple levels, from the Global Domain down to an individual Component and have a “scope.” Lower level Objects can override a higher level Object. Below is the order in which Key Value Pairs can be overridden:

    Object Description
    Global Contains all Environment variables and any “additional Key Value Pairs” set by the user when running that task.
    Environment Overrides any Global Key Value Pairs during a deployment.
    Application Overrides the Environment Key Value Pairsduring a deployment.
    Endpoint Overrides the Application Key Value Pairs during a deployment.
    Component Overrides the Application Key Value Pairs during a deployed.

    Key Value Pairs can be given any Name and a Value. Use +Add to add Key Value Pairs to the table. Use Save to confirm. Use the checkbox to Delete or Edit a Key Value Pair.

    Deployed Environments for Component

    A map showing all Environments where the Component is deployed.

    Consuming Applications

    This section shows a list of all Applications that are consuming this Component.

    Audit Trail

    The Audit Trail displays audit entries for any changes or deployments that impact this object. It includes all changes in the object including User date and time, and deployments with unique numbers.

    For deployment audits, select a deployment number to see the details including:

    Access Description
    Log The output of the deployment.
    Files Any files or objects deployed.
    Step Duration Deployment Steps with time required to execute.
    Feedback Loop Shows what was updated starting from Component.

    You can also Subscribe or Comment to an Audit Entry.

    • Subscribe: Allows you to receive information about the selected deployment.

    • Comment: Click on ‘Comment’ to add information. There is a field above the list labeled “Say something about this Application” that can have comments placed into it, and files can be attached to the comment as well. Entering text into this field activates the Add Message button. Click to save the comment as a line in the list.

    • Add Files to Comments: Click on the paperclip icon to add a file to the message. Once done, click on the “Add Message” button. These attachments can later be retrieved by clicking on the paperclip icon which then displays the name of the file within a list. Choose the file to download it into the your default Download directory on your local computer.

    Access

    The Access Section allows Users within designated Groups to update or view the Component. To add a Group to one of the access lists, drag and drop the Group from the Available Groups list onto desired access list. All Users who belong to a Group that appear in one of the Access lists will be granted access to the Component:

    Access Description
    View This allows any User that belongs to any Group in this list to see the selected Component in the List View.
    Change This allows any User that belongs to any Group in this list to make changes to the Component.

    DeployHub Pro Change Requests

    The integration of Change Request systems are supported in DeployHub through the use of a Data Source. To integrate Change Request you must first define a Change Request Data Source from the Data Source Dashboard. Once created, you will be able to select the Data Source from the General Details “Change Request Data Source” field of your Application and/or Component. When you have a Change Request Data Source defined, you can add issue tickets using the Change Request section of the Application or Component Dashboards.

    Creating Change Request Data Sources

    Jira, Bugzilla and GitHub are represented in DeployHub as Data Source Types. Because a Data Source is associated to a specific Component or Application you will need to map a unique Data Source for each system’s repository (Organization, Repository, Product, Project Key) where you are tracking the Component or Application. In a traditional release process, a Component and Application’s repository may be the same. Because microservices are often managed in their own repositories, you may need to define a Data Source for each of your microservice Components. For more on creating a Change Request Data Source see Managing Data Sources.

    Change Request that are tracked at the Component level are rolled up to the Application level. All change request associated to Components and Applications are rolled up to the Release.

    Once connected, the Change Request Section for the Component and the Application shows all Change Request manually added. If a Data Source has not been assigned, you will see a message “No Change Request Data Source has been setup.” Once setup, you can use the ‘+Add’ option to associate specific change request to the Component or Application. Selecting +Add will create a new row in the table with a drop down list box. This drop down will contain all change request retrieved by the Data Source. Select the Change Request and use the Save option to commit the new row to the table. Use the Edit option to switch a Change Request, or Delete to remove a Change Request.

    Publish a New Component Version Based on an Existing Component Version

    Create Component Versions that are patterned after the Component Base Version or any Component Version. Check the box Component Base Version or Component Versions from which you want to base the new version. Select the New Version Tab to access the Component Dashboard and then edit the new Component Version. When you manually create a new Component Version the name will be auto generated with a new number. You may need to provide it a unique name based on your versioning patterns.

    Publish New Component Versions automatically via Continuous Delivery

    Configure a continuous delivery system to automatically update new Component Versions each time a new GitCommit triggers the workflow process. Add DeployHub to the workflow to perform the continuous versioning of new Components and their consuming Applications. For more information, see Using DeployHub with CI/CD.

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