DeployHub and Continuous Delivery

Introduction to Life Cycle Subdomains

DeployHub uses a built-in deployment pipeline for tracking an Application’s journey across a software delivery Life Cycle, i.e. Dev, Test, Production. However, it is important to understand that a DeployHub Life Cycle Subdomain is not intended to replace your continuous delivery (CD) orchestration solution. In fact, there is integration that allows DeployHub to be called by your CD pipeline so it becomes part of your overall ecosystem for performing continuous configuration management and continuous deployment.

DeployHub tracks an Application’s configuration including where it is in the Life Cycle in terms of Environments. An Environment is assigned to a Life Cycle Subdomain. Therefore, we can track where a Component or Application is in the Life Cycle based on where it has been installed. Each Life Cycle Subdomain can contain multiple Environments. Regardless of what Environment an Application is running in, DeployHub can still track where it is in the Life Cycle process based on the Life Cycle Subdomain. This is the core function of Life Cycle Subdomains.

A Life Cycle Subdomain is the lowest level Domain. You can not create a Subdomain off of a Life Cycle Subdomain.

Using a Life Cycle Subdomain

When you create a Life Cycle Subdomain, you provide a means to include Life Cycle state information as part of your Application’s configuration. For each state of your software delivery Life Cycle, you create an associated Life Cycle Subdomain for your Application. You do this by using the Domain Dashboard. Navigate to your Application’s Domain, select the “All Subdomains are Life Cycles” checkbox, and then add your child Subdomains. All Subdomains will represent your Life Cycle process. You will need to navigate to the Environment Dashboard to add the Environments to your Life Cycle Subdomains.

Establishing the Progression Order of Your Life Cycle

You can force the progression of your Life Cycle process by adding a “Move” Task to the Life Cycle Subdomain. At the “Move” Task level, you define what Life Cycle Subdomain will be the next state (the “move to Domain). This is how DeployHub clearly defines the order of how an Application should progress through the Life Cycle, i.e. first development, then test, and finally production. A “Move” Task does not perform a deployment, it just stages the Application for a deployment into the Environments associated with that Life Cycle Subdomain.

To deploy an Application into an Environment make sure that the Deploy Task is assigned to the Domain. The Deploy Task is the default Task for all newly created Domains.

Your Life Cycle Subdomains and your Continuous Delivery Engine

Your continuous delivery (CD) engine will define your Life Cycle progression. When you integrate DeployHub into your existing CD Pipeline, you will need to define your Life Cycle Subdomains to mimic your CD Workflow progression. You can then associate integration of each of your CD Workflows directly to a DeployHub Life Cycle Subdomain. You can perform calls to DeployHub to both “Move” and “Deploy” Applications into Environments. If you are a DeployHub Pro users, you can also call “Request” and “Approve” Tasks as part of your integration. These Tasks interact with DeployHub Pro “Smart” calendars, not available in DeployHub Team.