Defining Components

How to Publish Components to Domains

Component List View allows Adding or Deleting

Use the Component List View accessible from the left hand Component menu option to manage your Components Base Version and Component Versions. Because each Environment has a row where the Component Base Version or Component Version has been deployed, there can be multiple entries for the same Component if it has been deployed to multiple Environments. A list of all Components is organized by the following:

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

Note: If you have not defined any Components to Ortelius, you will see only the sample data.

You can also use the Filter bar, represented by a funnel icon, to reorder your Component List View:

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

Additional Tabs from the Component List View

Tab Description
Refresh Refreshes the browser.
+Add Base Allows you to Add a new Component Base Version. You will select from one of three types: Container, Application File, Database
+Add Version Creates a copy of the selected Component.
Delete Deletes the selected item. However, you must delete the Components starting from the newest to the oldest. The Component Base Version would be deleted last. Sorting by “Version” gives you the order.
List Return to List View if in the Map View.
Map Displays a global Map of all Component versions, with their Application relationships.

Component Types

When adding new Components select the Component Type from the drop down list/:

Type Description
Container For Containers such as Docker.
Application File For binary files such as .jar, .war, .ear, .exe, .dll, Linux executable files, Oracle Forms, or similar artifacts.
Database For SQL files such as .ddl or other database update scripts.

How to View and Edit Components

Components are defined as Container, Application File, or Database. These are the different types of Components you may need from microservices to binaries and DB updates. The Dashboard view displays all information related to a specific Component Base Version or Component Version. Depending on what type of Component you are defining, you will be presented with different data definition fields.

The following fields are common to all Components:

Field Description
Service Owner The owner of the Component, whose default value is the creator of the Component.
Service Owner Email The email of the owner. Important for knowing who to contact in the case of an anomaly.
Service Owner Phone The phone number of the owner.
PagerDuty Business Service URL Enter the address to the PagerDuty page that is associated to the business service for this Component.
PagerDuty Service URL Enter the address to the PagerDuty page that is associated to the Component itself.
Slack Channel Enter what Slack Channel that can be used to report issues about this Component.
Discord Channel Enter the Discord Invite Link you would like your consumers to use for this Component.
HipChat Channel Enter the HipChat Channel that can be used to report issues about this Component.
Full Domain The fully qualified path of the Domain that the Component is to be associated, showing all parent Domains.
Name The name of the Component.
Description A short text field with a description of the Component.
Component Type The kind of Component created, i..e. Container, Application File, or Database.
Endpoint Type Used to map the Component to Endpoints within an Environment at deployment. This allows Ortelius to map the Component to the correct Endpoint when moving across different environments. You can add your own Endpoint Types from the Customize Types menu or select from the default options.
Category Assigning a Category to an Object allows lists of Objects based on Categories to be used throughout Ortelius. Add a new Category in the entry field or use an existing Category displayed in the drop down.

A Container Component has the following optional attributes:

Field Description
Build Date The timestamp from when the last build job was run.
Build ID The internal identifier for the Build Engine.
Build URL The URL to the Build Engine.
Container Registry The Container registry where the Container is stored.
Container Digest The SHA number of the Container image.
Container Tag The tag that was assigned to the Container image.
Helm Chart The Helm Chart used to deploy the Component.
Helm Chart Namespace The sub-division of the Kubernetes cluster where your Component Container should run.
Helm Chart Repo URL Enter the URL to where the chart is located, for example: Bitnami, ArtifactHub, etc.
Helm Chart Version The Helm Chart Version from the Helm Repository.
Git Commit The Git SHA number. Populated when integrated into Continuous Delivery Pipelines.
Git Repo The Git Repository that triggered the build.Populated when integrated into Continuous Delivery Pipelines.
Git Tag The last tag for the Git Repository. Populated when integrated into Continuous Delivery Pipelines.
Git URL The URL for the Git Repository.Populated when integrated into Continuous Delivery Pipelines.

Application File Type Specific Data Definition

Field Description
Base Directory Base, or high level, directory where the file will be deployed. This value will be ignored if the Endpoint has a Base Directory defined. See Formatting Directories on the order of how the deployment directory is formatted.
Target Directory The directory under the Base Directory where the file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
Build Job The Continuous Delivery Build Job that is used to build/compile the Component.
Last Build Number The number of the last Continuous Delivery (CD) Workflow that created the files referenced within the Component. This number will default to the Build ID if one is not set by the CD Workflow.
Build ID The internal identifier for the Build Engine.
Build URL The URL to the Build Engine.
Build Date The timestamp from when the last build job was run.

Database Type Specific Data Definition

Database Components are used for making database updates such as table changes using SQL Scripts. Note: An database form (such as an Oracle Form) can be compiled and should be defined as an Application File not Database Component.

Field Description
Base Directory Base, or high level, directory where the file will be deployed. This value will be ignored if the Endpoint has a Base Directory defined. See Formatting Directories on the order of how the deployment directory is formatted.
Roll Forward Target Directory The directory under the Base Directory where the Roll Forward file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
Roll Forward Repository Choose the Repository that contains your Roll Forward SQL. This list box is populated based on the Repositories pre-defined in your initial setup. Based on the Repository you select, you may be provided override or append fields if they were made available. For more information on Repositories see Connecting Your Repositories.
  • Filepath Override: Enter a filepath that will override the default filepath defined at the Repository level.
  • Pattern Override: Enter a pattern that will override the default pattern defined at the Repository level. Patterns are file types you want to pull from the Repository, such as *.exe, *.dll, *.war.
  • Recursive Override: Select the box in order to override the default recursive behavior defined at the Repository level. This will turn recursion on or off depending on the setting at the Repository level.
  • Version Override: Overrides the default template of your versioning pattern defined at the Repository level.
Rollback Target Directory The directory under the Base Directory where the Rollback file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
Rollback Repository Choose the Repository that contains your Roll Forward SQL. This list box is populated based on the Repositories pre-defined in your initial setup. Based on the Repository you select, you may be provided override or append fields if they were made available. For more information on Repositories see Connecting Your Repositories.
  • Filepath Override: Enter a filepath that will override the default filepath defined at the Repository level.
  • Pattern Override: Enter a pattern that will override the default pattern defined at the Repository level. Patterns are file types you want to pull from the Repository, such as *.exe, *.dll, *.war.
  • Recursive Override: Select the box in order to override the default recursive behavior defined at the Repository level. This will turn recursion on or off depending on the setting at the Repository level.
  • Version Override: Overrides the default template of your versioning pattern defined at the Repository level.

Endpoints

This section lists all Endpoints that the Component has been installed to with its Deployment Number. The Deployment Number is generated by Ortelius for each unique deployment. You can also use this section to stop incremental deployments and force a specific version to be deployed to the Endpoint. By manually adding a specific Component Version to the Endpoint, you bypass the incremental deployment logic of the deployment engine. For example, if you would like to deploy a particular container without accepting any intermediate updates, you would go to the intermediate Component Versions and manually add them to the Endpoints, causing the deployment engine to believe that it was previously deployed. When you manually add an Endpoint, the Deployment Number will show “manually deployed.” To manually add a Component to an Endpoint, use the +Add option. You will be provided a list of available Endpoints. Use Save to commit the change to the table. You can select multiple Endpoints. To Edit or Delete an Endpoint, select the Endpoint and use the Edit or Delete option.

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:

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

Deployed Environments for Component

A map showing all Environments where the Component is deployed.

Consuming Applications

This section shows a list of all Applications that are consuming this Component.

Component Readme

Give your users more information about your Container, Application File or Database Component. You can upload an external readme file to provide any information that you need to convey to your potential consumers. Use the ‘Upload’ option to select a file. It must be in text format. You can also automate the upload - see below.

Component Swagger

Publish your Swagger API definitions to provide further information about your restful APIs and the parameters needed. Ortelius takes your .json or .yaml file and renders it using Swagger. Use the ‘Upload’ option to associate your .json or .yaml file to that specific Component Version. You can also automate the upload - see below.

Component SBOM

Publish your Component’s SBOM to show packages and licenses your Component is consuming. SBOMs are required for populating the CVEs.

Component Vulnerabilities

Component vulnerabilities are based on your SBOM. Every thirty minutes, Ortelius updates the Component vulnerabilities based on OSV.Dev. For more information refer to OSV.Dev section of this documentation.

Component License

Report the license associated with your code base for your Component. Use the ‘Upload’ option to import your License file into Ortelius. The file must be in a text format.

Automate the Readme, SBOM, License, and Swagger Upload via Your Pipeline.

You can automatically upload you readme, SBOM, License, and Swagger data using the Command Line Interface (CLI) added to your pipeline. For more information review the CI/CD CLI details. You will find a complete list of parameters for collecting Swagger, SBOM and other tool reports and results. .

Audit Trail

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:

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.

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.

Access

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

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.

Publish a New Component Version Based on an Existing Component Version

Create Component Versions that are patterned after the Component Base Version or any Component Version. Check the box Component Base Version or Component Versions from which you want to base the new version. Select the New Version Tab to access the Component Dashboard and then edit the new Component Version. When you manually create a new Component Version the name will be auto generated with a new number. You may need to provide it a unique name based on your versioning patterns.

Publish New Component Versions automatically via Continuous Delivery

Configure a continuous delivery system to automatically update new Component Versions each time a new GitCommit triggers the workflow process. Add Ortelius to the workflow to perform the continuous versioning of new Components and their consuming Applications. For more information, see Using Ortelius with CI/CD.

Component Dependency Map

The Dependency Map provides a graphical view of all Applications that is consuming this Component. This will remain empty until your Component is used by an an Application.

Last modified December 7, 2022: Added Swagger (69cbe9a)