Hipster Store Tutorial

The Hipster Store Test Drive.

Log in and Take a Test Drive

When you signup for DeployHub Team, you are asked for basic information, your UserID/Password, Company and Project names. Your UserID/Password and Company name are unique. Your Project will be a Subdomain under your Company Domain.

DeployHub is accessible through the following url:

https://console.deployhub.com/dmadminweb/Home

Login using the UserID and Password you used when you signed up for DeployHub.

The Online Store Company - Hipster Store Tutorial

This Hipster Store tutorial walks you through the basic concepts and Objects behind DeployHub. It also allows you to run a deployment in our hosted Kubernetes cluster (Google.) In DeployHub terminology, the Hipster Store is both an Application and a Subdomain. The Hipster Store belongs to a higher level Domain called the “Online Store Company”. We will first review and deploy an Application and then we will review the Application’s Components and how they are organized under Domains. We will review the “Online Store Company” Domain structure, and show how the Objects are organized using a Domain design.

Learn About Applications

An Application is a collection of microservices or Components that make up a complete software solution. In monolithic, we compile/link an Application, but this goes away in microservices. DeployHub puts the Application back together providing a “logical view” of the Application including the Components that it depends upon.

Applications are a collection of Components. Components are deployed to Environments. Environments are a collection of Endpoints. For more on each of these Objects see:

Step 1 - Deploy the Hipster Store Application

To get started, sign up for DeployHub. Once you login, you will have the opportunity to review the Hipster Store Application Base Version, Component Versions and the Hipster Store Environment. These are basic concepts important to understand. All security and DevOps attributes that DeployHub tracks are managed based on Component Versions, Application Versions, and Environments.

  • Select the Application Menu option from the left side of the DeployHub Home panel. This will bring you to a List View.
  • Checkbox the “Hipster Store;July 4th Sale.” This is the Hipster Store Application Base Version and it has not been previously deployed.
  • Select the Tasks option at the top of the List View and choose “Deploy Version to Environment.” This will bring you to a pop-up dialog box that allows you to select an Environment for the manual deployment. Select “Hipster Store Cluster.”

This process will deploy the Application to the cluster. Once the deployment completes and shows “success” in the results colum, double click on the “Hipster Store; July 4th Sale” to view the Dashboard. Take a look at:

  • The Dependency Map - this shows all of the Component Versions the “Hipste Store;July 4th Sale” consumes.
  • Log History - a list of deployment logs for this version of the Hipster Store.
  • Deployed Environments for Components - shows everything that was deployed for the cluster selected in the drop down box. For this base version, you deployed all Components.
  • Select the “Package Component” tab at the top of the Dashboard. This will take you to a blueprint designer. This designer is how you define your Application Base Version. The blueprint show which Components are being consumed by this Base Version. Notice on the right hand side there is a Component Selector. If you navigate through the tree view, you will see Domains where Components like microservices have been published. The Hipster Store reuses microservices from the “Purchase Processing” and “Store Service” as well as the “Front End” service from its own Hipster Store Domain.

Now lets do a second deployment by selecting a new version of the Hipster Store:

  • Select the Application Menu option from the left side of the DeployHub Home panel. This will bring you to a List View.
  • Checkbox the “Hipster Store;July 4th Sale;1_2_9_1.” This is a new version of the Hipster Store, called an_Application Version_ and it has not been previously deployed.
  • Select the Tasks option at the top of the List View and choose “Deploy Version to Environment.” This will bring you to a pop-up dialog box that allows you to select an Environment for the manual deployment. Select “Hipster Store Cluster.”

Once the deployment completes and shows “success” in the results colum, double click on the “Hipster Store; July 4th Sale;1_2_9_1” to view the Dashboard. Take a look at:

  • Log History - a list of deployment logs for this version of the Hipster Store. A new log will be available.
  • Deployed Environments for Components - This will show that only two microservices were deployed - new Facebook Component and a new version of the Currency Service Component. DeployHub used its versioning engine to determine which Components were already deployed to the cluster and only updated what changed.

Learn about Domains

Domains serve as the basic structure of organizing your microservice catalog. Developers use Domains to catalog microservices based on ‘solution spaces’ allowing them to both share their services and find others. Domains are not folders. They serve as a method for creating fully qualified names of Objects within DeployHub to keep things organized. You will learn how each Object is defined to a Domain and how the Object’s fully qualified name is derived. Domains also manage security and Tasks. When you assign security options and Tasks at the Domain level, any child Subdomain inherits the value. A child Subdomain can override a parent Domain value. Start exploring Domains from the left side main menu and selecting the Domain option. You will be brought to a sunburst map that shows the following three levels of Domains:

  • Global - the highest level Domain. This cannot be changed.
    • Online Store Company - A sample company configuration. See Hipster Store
    • Your Company Name - Your Company Domain Level
      • Your Project Name - A Subdomain of your Company Domain. This Domain can be defined with "Life Cycle Subdomains for managing a deployable software application using a Pipeline, or it can be used as a Catalog Domain for publishing Components such as microservices.

For our tutorial, we will explore the Online Store Company Subdomain and it’s child Subdomains. Click on the Sunburst Online Store Company Segment to view the child Subdomains.

  • Hipster Store - A Project Subdomain where our Application lives.
  • Purchase Processing - A Catalog Subdomain where microservices and other Components live that handles the purchase processing services for the entire fictitious Online Store Company.
  • Store Services - A Catalog Subdomain where microservices and other Components live that handle general services for the entire company.
  • Load Generator - A Catalog Subdomain where reusable testing Components live.

Each of these Subdomains have their own Subdomains. Let’s explore:

Step 1 - Explore a Catalog Subdomain

From the DeployHub home panel, select Domains on the left hand side Main Menu. Click on the “Store Services” Subdomain to see what it includes. You will see Subdomains that provide services for the following “Solution Spaces”:

  • Add Services
  • Email Services
  • Product Catalog Services
  • Recommendation Services
  • Cart Services

These Store Services Subdomains organize Components that can be reused by any other team for building out custom websites for our fictitious Online Store Company. You can also explore the Purchase Processing Subdomain to see how these solution spaces are organized. You can click on the center of the starburst map to navigate back up to higher level Domains.

Step 2 - Explore a Project Subdomain

Now lets take a look at our Hipster Store Subdomain. The Hipster Store Subdomain manages our Hipster Store Application. It also has Subdomains, but these Subdomains are refereed to as “Life Cycle Subdomains.” Life Cycle Subdomains are defined to contain Environments where your Application will be deployed. Life Cycle Subdomains cannot have any child Subdomains. It is the lowest level of Subdomain allowed.

Step 3 - Explore the Online Store Domain Details and Access

Return to the Online Store Company Domain by clicking anywhere in the center of the sunburst map. Details about this Domain is displayed to the right of the sunburst. You will see that is belongs to the “Global” Domain, shown by the field labeled “Full Domain.” You will also see that it has the “All Subdomains are Life Cycles” option set to “No” and a list of it’s child Subdomains. There are other details as well. For a full description see Building Your Domain Catalog.

The Access Control Section defines who can see this Domain and it’s child Subdomains. For this example, the “Everyone” Group is defined to all Access. The Everyone Group is a default DeployHub Group that includes all Users and Administrators. For more on Users see Managing Users.

Step 4 - Explore Tasks for the Online Store Company Domain

You used the “Deploy Version to an Environment” Task when you deployed the Hipster Store. Tasks allow you to perform steps related to deployments and are only needed by your Project 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 see.

You can assign Access to Tasks and customize them with Pre and Post Actions. For more on Tasks see Deployment Tasks.

Learn about Components

Components are microservices, binaries, database SQL, files or any deployable artifact used by an Application. Components themselves are not deployed, they must be consumed by an Application in order to be deployed to an Environment. With microservices, this may seem counter intuitive as microservices are independently deployable. This is true and DeployHub takes this into account during a deployment of an Application. DeployHub deploys using incremental processing which means if a single Component of an Application is updated, and the Application is deployed, only the single Component is moved. DeployHub does incremental processing of deployable objects, but relates them to a logical Application. If an Application pushes a new version of a single microservice Component to a cluster, it will move alone. Subsequently, all dependent Applications will have a new Application Version created.

Step 1 - Review the Hipster Store Components

Choose the Components Menu option on the left side of the DeployHub home panel. This will take you to a list view of all Component Base Versions and Component Versions. A Component Base Version is the original Component. When the Component is updated, a Component Version is created.

Double click on the “cartservice;v1_2_2_9_gcadf581” Component Version to explore the Component. You will be taken to the Dashboard view. You will see in the “Full Domain” field of the Details Section to what Domain the Component belongs. You will see all Applications that have a dependency on this version of the Component, and in the “Deployed Environments for Component” you will see all Environments where the Component has been deployed.

Learn about Environment and Endpoints

Environments are collections of one or more Endpoints where Applications are installed.

Step 1 - Review the Hipster Store Environment

Select Environments from the left hand side of the DeployHub main home panel. This will take you to a list of Environments. Double click on the “Hipster Store Cluster”. From the Dashboard view you can see how the Environment was setup. You can also see all of the Components installed on this cluster.

Step 2 - Review the Hipster Store Cluster Endpoint

Select Endpoints from the left hand side of the DeployHub main home panel. This will take you to a list of Endpoints. Double click on the “Hipster Store Cluster Helm Host” Endpoint. This Endpoint defines where Helm will execute to update the cluster. This Endpoint has been configured to talk to the Hipster Store Cluster. See Helm for Container Deployments for creating your Helm configuration file.

Conclusion

There are many other features of DeployHub that we did not get to cover on this short test drive. However, you should have the basic understanding of the major Objects and concepts needed to get you started. What we did not cover that you may want to view are:

We will leave you with how to setup DeployHub for your installation. See First Steps, for getting your setup completed. Once you have your setup complete you can start publishing Components, packaging Applications and performing deployments.

Another important topic is integrating with your CD pipeline. See Using DeployHub with CI/CD for how you can include continuous configuration management and continuous deployments into your CD pipeline.


Last modified January 16, 2024: fix broken link (5366b1f)