Creating Releases

Intro to Releases

A Release manages the progression and deployment of multiple Applications together. Releases and Release Versions are a DeployHub Pro feature. Releases and Release Versions are collections of one or more Applications that are managed as a unit due to their interdependencies. This is sometimes referred to as a “Release Train.” Like Applications and Components, Releases are versioned each time they are deployed. A Release Base Version is the initial version and acts as a model for subsequent Release Versions.

The Release List View for Adding or Deleting

Use the Release List View accessible from the left hand Release menu option, found under Advanced Features. This will take you to a list of all Release Base Versions and Release Versions to which you have access. There is a row for every Environment to which the Release Base Version or Release Version has been deployed. For this reason, you will see multiple entries for the same Release if it has been deployed to multiple Environments.

The list view is organized on the following columns:

List Column	Description
Version	The Release Base Version or Release Version number.
Domain	The Domain to which the Release belongs.
Parent	The Release Base Version from which the Release Version was created. This will be empty for the Release Base Version.
Environment	The Environment to which the Release 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.

You can also use the Filter bar, represented by a funnel icon, to reorder your Release List View. You can filter on:

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

By double clicking on an item in the list, you will be taken to the Dashboard view.

Additional Tabs from the Release List View

The Release List View has the following Tabs.

Tab	Description
Refresh	Refreshes the browser.
Add Base	Allows you to Add a new Release Base Version.
Add Version	Creates a copy of the selected Release in the list, creating a new Release Version.
Delete	Deletes the selected item. However, you must delete the Release starting from the newest to the oldest. The Release Base Version would be deleted last. Sorting by “Version” gives you the order.

Viewing and Editing with the Release Dashboard

The Dashboard view displays all information related to a specific Release Base Version or Release Version. Below are the Details for a Release.

Details	Description
Full Domain	The fully qualified path of the Domain that the Release is to be associated, showing all parent Domains.
Name	The Name of your Release.
Owner Type	Owned by a User or Group.
Owner	Name of User or Group.
Summary	Description of the Release.
Created	Auto generated based on the date the Release was added.
Modified	Auto generated based on the date the Release was updated.
Successful Deployment Template	The template that should be used for success notifications.
Failed Deployment Template	The template that should be used for failure notifications.

Assigned Applications

This section contains all of the Applications that make up the Release Version, linked together in order of deployment. Click on the tree structure on the right side in order to see all the available Applications, then click and drag an Application from the list on the right side and drop it into the Release area. It will appear in the area as a box containing the name of the Application and will automatically link to the last Application in the area. The connecting line can be deleted by right clicking on the connector line and selecting “Delete this Connector”. A new connector can be created by clicking on the anchor (the green dot at the bottom of the Application) and dragging and dropping it onto another Application. This determines the order that Applications will be deployed. Keep in mind that each Application contains Components, which contain Component Items, all of which are linked together in the order that they are executed.

NOTE: In the Application Version area, there is an object that represents the currently selected Release Version. It is distinguishable from any Applications in the area by the arrow icon that appears in the object along with the word “Start” and is positioned in the top center of the window and cannot be moved from that position. This must be connected to the first Application to be deployed, otherwise DeployHub Pro does not know which Application to begin with, and the deployment will fail.

Applications can be set to deploy in parallel by joining two or more applications to a common parent. In this case, when the parent application has been deployed the “child” applications are deployed in parallel. You can attach multiple application to the “Start” block in order to deploy the initial applications in parallel.

Log History

Releases can be deployed many times, to the same or different locations (Environments). For every Deployment, the Log History will show all deployments based on “Result” and “Date”.

Key Value Configurations

Key Value pairs are stored for any configuration setting that needs to be persisted with the version of the Object. For example, pairs can be used to store issue numbers from Jira or GitHub issues with the Component Version and/or Applications Version.

For users of the DeployHub Pro internal deployment engine, Key Value pairs can be stored by DeployHub Pro and referenced during a deployment.

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 Pairs during 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.

Trends

The Trends graph shows you your success or failure rates overtime as well at the time required for the last 10 deployments. If a Release deployment is taking longer than previous deployments, this might indicate an issue with your deployment logic.

Audit Trail

The Audit Trail displays audit entries for any changes that impact this Object.

• Comment: Click on ‘Comment’ to add information. There is a field above the list labeled “Say something about this Object” that can have written comments placed into it, or files can be attached to the comment. 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.

Deployment Audits

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.

When using the internal DeployHub Pro deployment engine, all log output is automatically persisted with the Application Version and Component Version.

If you are using another deployment solution, you can persist the log via the CI/CD workflow. The output from the deployment can be passed to the CLI to be persisted with the Application Version and Component Versions. Learn more about the CI/CD CLI Integration

Access

The Access Section allows Users within designated Groups to update or view the Release. 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 Release:

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.
Deploy	This allows any User that belongs to any Group in this list to deploy the Application. This is further restricted based on the Access defined at the Environment level.

DeployHub Pro Change Requests

The integration of Change Request systems are supported in DeployHub Pro 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 Pro 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.

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 Pro.
html_url	A URL which will direct a browser to the page describing the change request in the external change tracking system.

Planner Tab

This tab Contains Release Planner, which helps to plan and schedule the deployment of Releases and their Applications throughout the software Life Cycle. The Release Planner provides an overall view of the activities for a Release, which includes the Applications contained within the Release, the number of Defects for Components within each Application, and target Environments for the deployment of Releases and Applications, all in a linear Calendar format with drag and expansion capabilities. By viewing the number of open defects along with the scheduled testing time for each Application in the Release, Production Support Teams can easily make judgements as to whether the Release is on track or needs to be restructured or rescheduled.

The uppermost horizontal area of the Release Planner contains a Calendar that corresponds to the dates contained within Environments that the Release and its Applications are to be deployed to. The gray area beneath this represents the Release and contains any Environments that the Release will be deployed to. Beneath this is one or more areas, each for every Application contained within the Release.

Using the scrolling device on the User’s mouse or trackpad causes the entire area to expand and contract which, along with the ability to scroll back and forth via clicking and dragging, allows the User to easily view the entire Release Plan from beginning to end, in detail, while using the Calendar along the top as a reference.

There are pie charts as the first field in each Application that represent open and closed defects for Components contained in each Application. The gray section of each pie chart represents the number of closed defects, while the gold section represents the number of open defects. Hovering the pointer over a pie chart will show the actual number of open and closed defects. This is used to help with tracking defects at a glance so that they can be dealt with, thereby helping to prevent the failure or postponement of a deployment.

Within the Application areas are various colored blocks that represent a deployment in the Environment’s__Calendar in the form of either an Auto Deploy or a Reserved event. The label shown on the block refers to the domain that the target Environment is contained within. Hovering the mouse pointer over it will display the name of the Environment it will be deployed to. Clicking on a block will take the User to the Calendar entry for the designated Environment.

A red line indicates today and assists in identifying where deployments for Applications and Releases are in the schedule. The various blocks within the different areas are colored according to where they stand in the release plan. A gold block represents an overdue deployment into an Environment, and this is will always appear to the left of the red line. A slate colored block represents a completed deployment into an Environment. A dark blue block represents a deployment scheduled to take place in the future.