The first step in defining your Components is with your Component Base Version.


A Component Base Version is created with the Deploy Main Menu. Click the Component tab, right click a Domain in the tree structure, and select ‘New Component Base Version in this Domain’.  


Alternatively, you delete a Component by right clicking on it and then selecting the ‘Delete Component Version from this Domain.’ You cannot retrieve a Component once it is deleted.

Component Items Tab

This tab is used to create or edit Component Items and link them together so as to deploy them in a specific order. To create a Component Item, right click in the area within the Component Items tab. “Create New Component Item” will appear as the only row in the resulting drop -down list. Click on it, and a window will appear titled “Edit Item n”, where ‘n’ is an integer, which contains the following fields:


Field

Description

Name

The name of the Component Item.

Summary

A short text field with a description of the Component Item.

Roll-Forward

Used in the event that there is a Roll Forward taking place during a deployment. A Roll Forward takes place when the version being deployed is later than the version located on the target. This is determined by the order that the Application Versions are linked in on the Base Application's Versions tab and NOT by the Application Version name.


There are three possible values for this field.

On: Roll Forward from the Version on the Endpoint +1 to the version being deployed.


Off: Do not include in a Roll Forward.

All: Roll Forward from the Version on the Endpoint to the version being deployed inclusive.


For example: If pulling SQL files to apply alter scripts, the roll-forward flag should be set to "On" for the corresponding component item(s). If the Environment contains version 2 and we are deploying version 5, this will operate on version 3 (to roll the DB forward from version 2 to version 3), version 4 (to roll the DB forward from version 3 to version 4) and finally for version 5 (to roll the DB forward from version 4 to version 5).

Rollback

Used when there is a Rollback taking place during a deployment. This refers to  when the version being deployed is earlier than the version located on the target. This is determined by the order that the Application Versions are linked on the Base Application's Versions tab and NOT by the Application Version name.


There are three possible values for this field.

On: Rollback from the Version on the Endpoint to the Version being deployed + 1


Off: Do not include in a rollback.


All: Rollback from the Version on the Endpoint to the Version being deployed inclusive.


For example: If pulling SQL files to apply rollback scripts, the roll-back flag should be set to "On" for the corresponding component item(s). If the Environment contains version 5 and we are deploying version 2, this will operate on version 5 (to roll the DB back from version 5 to version 4), version 4 (to roll the DB back from version 4 to version 2) and finally for version 3 (to roll the DB back from version 3 to version 2).

Target Directory

The Base Directory for a Component can either be absolute or relative. If it is absolute, i.e. 'c:\main' for Windows or '/main' for Linux/Unix, etc., then it replaces the Base Directory for the Endpoint. If the Component's Base Directory is relative, i.e. 'SomeFiles\SomeMoreFiles', then it is appended to the Endpoint's Base Directory, i.e. 'c:\main\SomeFiles\SomeMoreFiles'.

If the Component Item's Target Directory has a value, it is always appended to the end of whatever value has been created from the Base Directories of the Endpoint and Component.

Repository

A required field, this is the Repository where the files to be deployed are located. Clicking on the field presents a drop-down list containing the names of all of the Repositories within the DeployHub installation to which the current User has access. Selecting a Repository will change the Modifiable Repository Properties fields to include:

  • Any Property that has not been defined at the corresponding Repository Level.
  • Any Property that has been defined at the corresponding Repository Level but is marked as being either overridable or appendable.


Component Items are connected to determine the installation order when the Component is deployed. In order to connect two Component Items, click on the small green dot, or anchor, on the bottom of a Component Item. Drag the anchor and drop it onto the top anchor of the Component Item that should follow it. A connector will now exist between these two Component Items, and they will be installed in that order.

Versions Tab

Create Component Versions that are patterned after the Component Base Version. To do this, right click in the Component Versions area within the Versions tab, and “Create New Component Version” will appear as the only row in the resulting drop-down list. Select this and a new version of the Component Base Version will appear as a box in the Component Version’s area. It will be named after the Component Base Version along with an integer, separated by a semicolon, i.e, “myComponent;1”.


Each subsequent Component Version will have incremental number changes. You can rename these. They are linked automatically or by clicking the anchor on the bottom of one Component Version and dragging and dropping it on the top anchor of another. When this is done, the Component Items of the linked Component Version are changed automatically to those of the  connected Component Version.


The connecting links can be deleted by right clicking on the link and selecting “Delete this Connection”.  Component Versions can have multiple Child Versions, that is have multiple connections from its bottom connector. This can be used to indicate different development branches. You can label a branch by right-clicking on the relevant link and selecting "Add Branch Label".


The links for Component Versions is not used in the same way that they are for Application Versions (where they are used to determine the order of Application Deployment during a roll forward or rollback deployment) or Component Items (where the links determine the deployment order). They are used merely for showing the branching of different Component Versions as they are created over time.


Clicking the Plus ‘+’ sign next to a Component Base Version in the tree structure causes it to expand and display all Component Versions for the selected Component Base Version. Clicking on one of these causes the tabs to change on the right side of the main window which includes all of the tabs for the Component Base Version, with the exception of the Versions tab. These tabs work the same for the Component Versions as they do for the Component Base Version.


NOTE: Alternatively, you can create a Component Version by clicking on a Component Base Version in the tree structure, selecting the Versions tab on the right, then right clicking on the Component Versions area. This brings up a drop-down list with “Create New Component Version”. Clicking on this creates a new Component Version for this Component Base Version, and names it by using the name of the Component Base Version followed by an incremented integer, separated by a semicolon, i.e., “MyComponent;1”.

Timeline Tab

Audit entries for deployments with this tab, including deployment number, Environment, and how many days ago the deployment (or hours for all of today’s deployments) took place. Any attribute changes to the Component are also shown on the timeline.

Timeline Comments

Users can add comments to entries in the timeline by clicking on the ‘Comment’ link within each entry, which opens a text entry field just below the deployment information. Click on the ‘Click to see earlier items’ link to see other audit entries.  


There is a field labeled “Say something about this Component?” above all deployment lines 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 on this button to save the comment as a new audit entry.

Adding Documents to the Timeline

Clicking on the paperclip button next to the Add Message button brings up a file explorer that allows multiple files to be selected and attached to the comment. Comments with files attached are shown with a paperclip. Clicking on the paperclip expands the audit entry to show the files attached to the comment as hyperlinks. Clicking on the link will download the file. This process in browser-specific.

Subscribe to Components

Users can also click on the Subscribe link in each entry of the list, which places the audit entry into the User's personal Timeline. Any comments added to the audit will appear in the Timeline tab of the subscriber’s home page.

Endpoints & Builds Tab

This tab contains a table that shows which Component Versions have been installed on Endpoints within Environments. The fields in the table include Environment, Endpoint, Component Version, and Details.


If a Component Base Version is selected, then the Deployed Endpoints Tab will show all the Component Versions of the selected Component Base Version and where they have been deployed. If a Component Version is selected, the display will be limited to only the Endpoints to which that Component Version has been deployed.

Assigned Applications Tab

This tab contains a table showing to which Application Versions the selected Component is assigned. There are two fields, Application Version and Component Version. This table can be viewed as a kind of quick reference in order to inform the user of which Applications will be affected by changes to Component Versions. Clicking on any of the values in the list will take the User to that object.

Attributes Tab

This tab allows the creation of values that are stored against an object and can be used to control deployments. The Name field holds the name of the value, and the Value field holds the data, which can be either a numeric or text value. It can also be an array of Name/Value pairs. Clicking on a blank Name field allows the user to enter a new Name, and then tab into and enter its associated Value.


To enter the values for an array use the following syntax for the Name:


name[subscript]


You can enter multiple names with different subscripts to create an array. These need not be numeric since arrays in DeployHub are associative.

Access Tab

You can assign Groups which contain Users to View and Change access to Component. There are two Access options for Component:


Access

Description

View

This allows any User that belongs to any Group in this list to see the selected Component in the tree structure on the right side.

Change

This allows any User that belongs to any Group in this list to make changes to the Component.


General Tab

The General tab contains basic information about the Component:


Field

Description

Name

The name of the Component.

Owner

The owner of the Component, whose default value is the creator of the Component. The default owner is the User who created the Component. When editing this field, the Owner Type field is available which includes Owner and Group as choices. Selecting one of these causes the Owner field to display either Users or Groups to choose from.

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 time the Component was changed.

Component Type

Used to match the Component to Endpoints within an Environment when deploying. An Endpoint can be assigned many different Component Types, and a Component can have only one Component Type assigned to it. This allows an Application containing many different Components to be deployed into an Environment, with each Component only deploying to its matching Endpoints.

Change Request Data Source

This Data Source is assigned to the Component, and Change Requests can then be assigned to the Component in the Change Requests tab.

Build Job

The Jenkins Job that is used to build/compile the Component Item(s) in this Component.

Last Build Number

The number of the last Jenkins build that created the files referenced within the Component’s Component Item(s).

Category

Categories allow the selection of Components in an orderly manner. Assigning a Category to a Component allows lists of Categories to be used throughout DeployHub. Clicking on an individual Category expands the list, and shows all of the Components that belong to that Category.

Always Deploy

The Component is deployed to the associated Endpoint(s) in the Target Environment regardless if the Component is already present on the Endpoint(s).

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.

Base Directory

The Base Directory for a Component can either be absolute or relative. If it is absolute, i.e. 'c:\main' for Windows or '/main' for Linux/Unix, etc., then it replaces the Base Directory for the Endpoint. If the Component's Base Directory is relative, i.e. 'SomeFiles\SomeMoreFiles', then it is appended to the Endpoint's Base Directory, i.e. 'c:\main\SomeFiles\SomeMoreFiles'.

Note that the Target Directory for each Component Item in the Component is always appended to this combined path.

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. It is executed after all of the files have been pulled from the Repositories referenced in the Component Items associated with the Component but before they are deployed to Endpoints in the target Environment.

Post-Action

An Action that is to be run before the deployment of this Component. This can be used to execute actions on the target Endpoint after the Component has been deployed.

Custom Action

An Action that replaces the usual Deployment Engine processing. Custom Actions can be used when the normal component-level deployment is not suitable for the deployment of the Component. No Component Items are used if a Custom Action is being used.