Building Your Domain Catalog

A Domain Driven Design

A DeployHub Domain is how DeployHub organizes and shares data across teams. You publish your microservices to a Catalog Domain, you package your Application in a Project Domain and you track your continuous delivery pipeline with a Life Cycle Domain. All DeployHub objects are assigned to a Domain.

Domains and your Domain Driven Design

A Domain Driven Design is critical for organizations moving from monolithic development to microservice development. In microservices, you must have a structured method for organizing microservices into “solution” spaces to facilitate reuse across siloed teams. DeployHub Domains provides this organization.

Domains catalog and publish microservices and other reusable objects (web components, DB updates, etc.) making it easier to share these microservices and Components across siloed teams. Domains can be structured to closely resemble the patterns of your organization. They can represent functional areas such as ‘security services’ or departments, teams, geographical locations and software projects.

Top Down Structure

Everyone has a single high-level “Global” Domain. All other Domains are Subdomains. For SaaS Users, your sign-up form asked you for a “Company” and “Project.” These values were used to create your initial Domains. If you are using a locally installed version (on-prem), your highest level Domain will be “Global” and you will need to create your own Domains.

A Subdomain inherits all the access properties from its parent Domain. This inheritance continues down through all Subdomains.

There are four common ways to implement Domains:

Purpose	Description
Site Domain	This is the highest-level and default Domain. For SaaS Users, your Site Domain will be defaulted to the Company name from your registration. You can rename your Site Domain if needed. For an On-Premise installation, your default Site Domain name is ‘Global.’ You can rename your Site Domain if needed. Anything defined to this level can be shared across all lower level Subdomains. For example, Environments and Tasks defined to the Site Domain are shared by all child Subdomains.
Catalog Subdomains	These Domains are used to organize reusable Components, such as microservices. At this level, you create as many Subdomains as needed to represent your Component organization based on the “solution space” they serve. For example, you could build your Catalog as follows: Security Services Purchase Processing Data Access Ad Services A Catalog Domain does not contain Life Cycle Domains.
Division Subdomains	DeployHub Pro Users can take advantage of Division Domains. Larger companies can define a catalog to share Components based on geographical areas, organizational responsibility, or business units. A Division Subdomain can have many child Subdomains. For example, a Catalog Subdomain for Security and Purchasing Services could be broken down into further Subdomains: Security Services Login Services Payment Processing Services Merchant Services EMEA Shipping Services North America Shipping Services Purchase Processing Services EMEA Check-out Services North America Check-out Services
Project Subdomains	Use a Subdomain to represent your software Application and its Life Cycle. A Subdomain defined for an Application may need a continuous delivery life cycle. This is defined by selecting “All Subdomains are Life Cycles.” This means that any Subdomains cannot include any additional Subdomains and will be used to represent stages of the Pipeline with specific Environments assigned.
Life Cycle Subdomains	This is the lowest level of Subdomain. It is available when the parent Domain has “All Subdomains are Life Cycles” selected. These Subdomains map to each stage in your continuous delivery pipeline. They often have specific Environments and Tasks assigned for interaction with your continuous delivery orchestration engine. DeployHub can be called by your continuous delivery Engine (Jenkins, Jenkins X, CircleCI, Google CloudBuild, GitLab or GitHub Actions, etc.) to perform the continuous configuration management of your microservices and Applications across all lifecyle states. In addition, you can assign Move, Approve and Request Tasks to your Life Cycle Subdomain to define a continuous delivery pipeline process within DeployHub that can interact with your pipeline process.

Below is an example of how the Online Store Company Domains have been defined. For SaaS users, you can review this by inspecting the Online Store Company Domain.

Using the Domain Dashboard

A full view of all Domains is based upon your User privileges. The view is displayed in a “Sunburst” map, starting at the highest level Domain with the ability to drive down into the Subdomains, and Subdomains after that. Clicking on a segment in the Sunburst map will take you to that Domain. Clicking on the center of the Sunburst will take you back up the Domain structure.

When scrolling up or down the Domain hierarchy using the Sunburst map, the detail information is re-displayed according to where you are in the map. Below are the details for a Domain.

Domain Details

Details	Description
Full Domain	The fully qualified Domain Name including any parent Domains.
Name	The Name of the Domain.
Summary	Domain Description.
Owner Type	User or Group.
Owner	Name of the Owner.
Created	Auto-generated date when it was created.
Modified	Auto-generated date when it was modified.
Engine	The hostname of the deployment engine. Defaults to “Deployment Engine.” This field can be used to specify another DeployHub Deployment Engine for widely distributed deployments.
All Subdomains are Life Cycles	This specifies that the Domain will include a Pipeline model and all following Subdomains will model the pipeline states. Life Cycles are specifically for Project Subdomains. Life Cycle Domains cannot have any further Subdomains and are not appropriate for defining a Catalog Domain.
Subdomains	A list of all Subdomains assigned to this Domain.

Access Control

Users within designated Groups can update the Domain in various ways. To add a Group to one of the access lists, drag and drop the Group from the Available Groups list onto the desired access list. All Users who belong to a Group in one of the Access lists will be granted access to the Domain. Access control for Domains include:

Access	Description
View	Allows the Group to see the Domain.
Change	Allows the Group to change the Domain’s characteristics i.e. Name, Summary, etc.
Read	Allows the Group to see the Domain.
Write	Allows the Group to create Subdomains.

Deployment Tasks

Task are used for executing deployments, managing approvals, or staging a deployment. Tasks can be assigned to any Domain. However, they are most commonly associated to Project Domains and Life Cycle Domains. You can assign a Task at a higher Domain level allowing any child Domains to automatically inherit the Tasks. This inheritance simplifies managing Tasks by making some common to all of your Subdomains. However, this means that a Catalog Domain may include Tasks that it cannot use.

The following Tasks are available as default Tasks, but you can create any type of custom Task. A custom Task will call a Custom Action:

• Move Version to the Next or Previous Pipeline State
• Deploy Version to Environment
• Manually Trigger Action to be executed

DeployHub Pro

DeployHub Pro includes a “smart” Calendar. The following Task are used to interact with the DeployHub Smart Calendar for Requesting and Approving deployments.

• Request Calendar Entry for Deployment to an Environment
• Approve Version for Move to Next Pipeline State

Adding, Editing and Deleting Tasks

You can add new Tasks from the Domain Dashboard by navigating to the Domain and interacting with the Tasks Section. Select the +Add option from the Tasks Section and a pop-up displays all available Tasks. Selecting a Task will add a new row into the table. Use the Task Detail Section to define the unique details of your new Task. You can update or remove a Task by using the Task Section table. Using the checkbox, select the item and use the the Delete or Edit options.

Once you create a Task, it is recommended that you rename that Task to more closely describe its use depending on the options selected.

Below is a description of all Tasks and their detailed information.

Move Version to the Next or Previous Pipeline State

Moves an Application or Release version from one Pipeline state (Life Cycle Subdomain) to another. This can be used as a promotion or a demotion of an Application or Release version between Life Cycle states. When the Task is defined, the Life Cycle Subdomain has to be specified as part of the Task definition. The Approval Task must be accepted before the Move Version is to succeed.

“Move” Task Detail Fields	Description
Name	The unique name of the Task.
Created	Auto-generated date and time the Task was added.
Modified	Auto-generated date and time the Task was updated.
Pre-Action	Change the default behavior by assigning a custom Action to execute as a Pre-processing step.
Post-Action	Change the default behavior by assigning a custom Action to execute as a Post-processing step.
Available in Subdomains	Once selected, all Subdomains will have access to this Task.
Move To Domain	The target Domain where the version will be moved.
Success Notify Template	The Notify Template emailed on a successful move. You need to define the Notify Template from the Setup Menu. See more on Notify Templates.
Failure Notify Template	The Notify Template emailed on a failed move. You need to define the Notify Template from the Setup Menu. See more on Notify Templates.

Deploy Version to Environment

Deploys an Application or Release version to an Environment. Select the target Environment via a drop-down list.

“Deploy” Task Detail Fields	Description
Name	The unique name of the Task.
Created	Auto-generated date and time when added.
Modified	Auto-generated date and time when updated.
Pre-Action	Change the default behavior by assigning a custom Action to execute as a Pre-processing step.
Post-Action	Change the default behavior by assigning a custom Action to execute as a Post-processing step.
Available in Subdomains	If selected, all Subdomains will have access to this Task.

Manually Trigger Action to be executed

Runs a stand-alone Action. For example, if you need to interrupt a deployment process, this Task allows you to execute the steps manually. The manually triggered Action will be placed in the “To do” list of the User or Group that executed the Deploy Task.

“Manually Trigger” Task Detail Fields	Description
Name	The name of the Task - can be changed to make the Task unique.
Created	The auto generated date and time the Task was added.
Modified	The auto generated date and time the Task was updated.
Pre-Action	You can change the default behavior by assigning a custom Action to execute as a Pre-processing step.
Post-Action	You can change the default behavior by assigning a custom Action to execute as a Post-processing step.
Action to Run	The Action that will be executed manually.
Available in Subdomains	If selected, all Subdomains will have access to this Task.
Success Notify Template	The Notify Template that will be emailed on a successful Action. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.
Failure Notify Template	The Notify Template that will be emailed on a failed Action. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.

Approve Version for Move to Next Pipeline State

Approves the Application or Release version so that it can be moved to a specified state in the pipeline (Life Cycle Subdomain). This works in conjunction with the Move Version Task. When the Approve Task is defined, the Target Domain has to be specified. When the Approve Task is executed, the selected Application or Release version can either be Approved or Rejected. Only when the an Application or Release version is “approved” can it be “Moved” or “Deployed”.

Note: When an Approve Task has been defined for a Domain, it will force the use of the Approve Task before a “Move” or “Deploy” Task can be executed. If a “Move” or “Deploy” Task is attempted but has not been “Approved,” an error will be displayed indicating that the Task must be Approved.

“Approve” Task Detail Fields	Description
Name	The name of the Task - this information can be changed to make the Task unique.
Created	The auto generated date and time the Task was added.
Modified	The auto generated date and time the Task was updated.
Pre-Action	You can change the default behavior of this Task by assigning a custom Action to execute as a Pre-processing step.
Post-Action	You can change the default behavior of this Task by assigning a custom Action to execute as a Post-processing step.
Available in Subdomains	If this is selected, all Subdomains will have access to this Task.
Approval Domains	The target Domain that approval is the subject of.
Approval Notify Template	The Notify Template that will be emailed on approval. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.
Rejected Notify Template	The Notify Template that will be emailed on rejection. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.

Request Calendar Entry for Deployment to an Environment

DeployHub Pro feature. Sends a request from a User to add a time slot to the calendar for a deployment. The request is sent to Group who has the authority to manage a particular Environment’s Calendar. When the Request Task is defined it is linked to the task to be requested. When the Request Task is executed an entry is placed into the “To Do” list of all the Users who are members of the Group with the calendar access. The Request Task can have a Request Notification Template defined which can send out a notification to the appropriate Groups.

“Request” Task Detail Fields	Description
Name	The name of the Task - can be changed to make the Task unique.
Created	The auto generated date and time the Task was added.
Modified	The auto generated date and time the Task was updated.
Pre-Action	You can change the default behavior by assigning a custom Action to execute a Pre-processing step.
Post-Action	You can change the default behavior by assigning a custom Action to execute a Post-processing step.
Available in Subdomains	If selected, all Subdomains will have access to this Task.
Linked Task	The target Domain where the version will be moved.
Request Notify Template	The Notify Template emailed for the request. You will need to define the Notify Template from the Setup Menu. See more on Notify Templates.

Task Execute Access

Once a Task is defined, it must be granted execute access to a Group before it can be invoked. Select the Task using the check box. Drag the desired Group from the Available Groups column to the Group Access area. Users of the Group can then execute the specified task.

Groups are assigned authority on a Task by Task basis. It is possible for a Domain to have two different Tasks with the same function, one of which allows a particular Group to run the Task, and the other which doesn’t. This allows similar Tasks to be created. They can have different characteristics assigned to them such as Pre-Actions and/or Post-Actions, Notification Templates, etc. Also different User Groups can have the authority to run them.

• Example: A Group can run a “Move” Task, sending an Application Version from the Test Life Cycle State to the Production Life Cycle State. A Group consisting of testers perhaps does not have the ability to run that same Task.

• Example: A Move Task is linked to a Request Task. A User in the Test Group would run the Request Task, which notifies Users in the Release Group and requests that the Application Version be moved. Users in the Production Group would then receive the Request Task through their To Do List and optionally an email (which was designated as the Request Notification Template in the Request Task). They would then run the linked Move Task to move the Application Version to the Production Life Cycle State.

NOTE: Another way to accomplish this is to link an Approval Task to the Request Task. The User in the User Group would send the Request Task, and a User in the Admin Group would be notified. They would then run the Approve Task to allow the User in the Test Group to run the Move Task.

Additional Task Parameters

Additional parameters can be added to a Task. These additional parameters will set Global Variable at execution time. To add them, select the Task from the Task Section. Use +Add to create a new entry into the Parameters table for the selected task. It will have two columns:

• Label: This will appear on the Task’s execution window whenever the Task is executed.

• Variable: An Entry, Password, or Dropdown field appears to the right of the Label whenever a Task is executed, where values can be either entered or selected, depending on the Type.

Use the Save to commit the change to the table. Use Edit to update a Task Parameter, or Delete to remove a Task Parameter.