Defining Your Application Baseline
Using the Application List View for Adding or Deleting
Use the Application List View accessible from the left hand Application menu option. This will take you to a list of all Application Base Versions and Application Versions to which you have access. There is a row for every Environment to which the Application Base Version or Application Version has been deployed. For this reason, there will be multiple entries for the same Application if it has been deployed to multiple Environments.
The list view is organized on the following columns:
|Version||The Application Base Version or Application Version number.|
|Domain||The Domain to which the Application belongs.|
|Parent||The Application Base Version from which the Application Version was created. This will be empty for the Application Base Version.|
|Environment||The Environment to which the Application 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 Application List View by:
- Last Deployment
Double click on an item to see the Dashboard view.
Additional Tabs from the Application List View
The Application List View has the following Tabs.
|Refresh||Refreshes the browser.|
|Add Base||Allows you to Add a new Application Base Version.|
|Add Version||Creates a copy of the selected Application in the list, creating a new Application Version.|
|Delete||Deletes the selected item. However, you must delete the Applications starting from the newest to the oldest. The Application Base Version would be deleted last. Sorting by “Version” gives you the order.|
|Tasks||Displays all Application Tasks available for the selected item based on the Tasks defined to the Application Domain. See Tasks for more information.|
|List||Displays the List View.|
|Map||Displays a global Map of all versions of the Application with Components.|
Viewing and Editing with the Application Dashboard
The Dashboard view displays all information related to a specific Application Base Version or Application Version. The Dashboard view has two additional tab options - Package Components and Versions. Below are the Details for an Application.
|Full Domain||The fully qualified path of the Domain that the Application is to be associated with, showing all parent Domains.|
|Name||The Name of your Application.|
|Owner Type||Owned by a User or Group.|
|Owner||Name of User or Group.|
|Summary||Description of the Application.|
|Created||The date the Application was added.|
|Modified||The date the Application was updated.|
|Change Request DataSource||DeployHub Pro Option - Establishes the Change Request system for the Application. A Change Request Data Source must be pre-defined for this field to be used.|
|Pre-Action||An action executed prior to the deployment.|
|Post-Action||An action executed at the completion of deployment.|
|Custom Action||Overrides any Pre or Post Actions, such as calling an external solutions such as Helm.|
|Successful Deployment Template||Used for success notifications.|
|Failed Deployment Template||Used for failure notifications.|
Application Dependency Map
The Dependency Map provides a graphical view of all your Package Components. This will remain empty until you assign Components to your Application. Do this by using the Package Components tab at the top of your Application Dashboard.
Applications 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 Configurations are Value Pairs for managing associative arrays assigned to the Object.
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:
|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 Pairsduring 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.
Each Application Base Version is assigned the Environments to which they will be deployed. Application Versions inherit the Environments from the Application Base Version. By using the “+Add this Application to an Environment to enable Deployments” option, you can add Environments where the Application is to be deployed. You can assign the Application to as many Environments as needed. The Detail field will contain a link to the deployment Log for the last Environment where the Application was deployed.
Last Deployment Difference Based on Environment
The Difference Graph shows what changed in the last deployment between the previous deployment. For the Application Base Version all Components will be shown. Subsequent deployments will only show changes.
The Audit Trail displays audit entries for any changes or deployments that impact this object. It includes all changes in the object including User date and time, and deployments with unique numbers.
For deployment audits, select a deployment number to see the details including:
|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.|
You can also Subscribe or Comment to an Audit Entry.
Subscribe: Allows you to receive information about the selected deployment.
Comment: Click on ‘Comment’ to add information. There is a field above the list labeled “Say something about this Application” 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 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.
Users within designated Groups can update or view the Application. 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 within an Access lists will be granted access to the Application:
|View||Any User in any Group within this list can see the selected Component in the List View.|
|Change||Any User in any Group within this list can make changes to the Component.|
|Deploy||Any User in any Group within this list can deploy the Application. Restrictions are based on the Access defined at the Environment level.|
The Trends graph shows the success or failure rates overtime as well at the time required for the last 10 deployments. If an Application deployment takes longer than previous deployments, there is an issue with the deployment logic.
DeployHub Pro Change Requests
The integration of Change Request systems are supported in Ortelius 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 Ortelius 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.
Package Components Tab
This tab contains all the Components that make up an Application, linked together in order of deployment if needed using a blueprint designer. Click on the Component Selector on the right side to see the available Components based on Domains and Categories. A Category acts as a tag or label assigned at the Component level and are not specific to Domains. Domains are identified with a sitemap icon. A Category is identified with a Tag icon. Selecting either expands the options to show all available Components.
Click and drag a Component from the list on the far right side and drop it into the Assigned Components area. It will appear in the area as a box containing the name of the Component. It automatically links to the last Component. Right click on the connecting line, select “Delete this Connection”.Create by Click on the anchor (the green dot at the bottom of the Component) to create a new connector. Then drag and drop it onto another Component. This determines the order in which the Components will be deployed. Each Component contains Component Items also linked together in the order to be executed. For a microservice implementation, they can all be linked to the “start point”. This means they will be deployed in parallel.
NOTE: At least one Component must be connected to the “start point” or the deployment will fail.
How to Publish New Application Versions Automatically via Continuous Delivery
Configure a continuous delivery system to automatically update new Application versions each time a new GitCommit triggers a new Component to be consumed by your Application. Ortelius in the workflow performs this continuous versioning of new Components and their consuming Applications. For more information, see Using Ortelius with CI/CD.