Overview of Ortelius Objects and Concepts

Introduction

Ortelius’ core objects are Domains, Applications, and Components. Components are the the objects that are cataloged, versioned and mapped across software supply chain. Environments and Endpoints are used to track releases to your clusters, cloud, or physical data centers and are referenced during your pipeline deployments for inventory control.

Domains are core to Ortelius’ management of microservices. Domains are hierarchical and pass inheritance from parent to siblings. For this reason, Components can be shared across the Subdomains. The hierarchical structure of Domains provides a high-level of control and management over how microservices are shared and reused.

Other Objects include:

• Date
• User
• UserGroup (Admin or User)

These Objects can be referenced using Ortelius APIs.

Following is a description of each Object and their attributes.

Application Object

Applications are a collection of Components that can be deployed as a single software solution. You define an Application by associating the Components it will consume. The first version is the Application Base Version. When you change this Application Base Version, you create a new Application Version. Applications are assigned and deployed to Environments. Applications are associated to a Domain.

• Application Base Version : Defines the software product in terms of Components, Attributes, and assigned Environments.

• Application Version : This represents any changes made in to the Base Versions.

An Application has the following properties:

Property	Description
id	A unique identifier for the Application in the database.
name	Application name.
fqdomain	Fully qualified Domain name.
summary	Summary of the Domain.
owner	User or Group that owns it.
parent	The Base Application.
predecessor	Predecessor Application Version.
Applications	Multiple Applications used to create a Release.
Components	The objects that the Application consumes.
approvals	Allows a control point for progressing a change within the pipeline process.
requests	The Change Request objects associated with this Application.
creator	The User or Group who created it.
modifier	The User or Group who last modified it.
ctime	The date/time it was created.
mtime	The date/time it was last modified.
KV Configurations	Key Value Pairs for managing associative arrays.

Component Object

Ortelius manages microservices and other reusable objects as Components. These are assigned to an Application even though they are managed independently. By assigning Components to Applications you track a ’logical’ view of your software solution. In a monolithic approach, this happened at the software compile and link step. In microservices though, they are loosely coupled and linked at run-time. Defining Components to Applications puts the Application back in the picture, even if it is only a ’logical’ view.

If you are an API or microservice developer, this will be where you do most of your work. However, application developers may also define Components for a specific Application. Components are microservices (containers), Database updates, or other deployable objects. By tracking the low level deployment metadata for a Component, it can be easily shared and released in a consistent way across team.

Components change over time, and so Ortelius contains Component Base Versions and Component Versions like those of Application Base Versions and Application Versions. And like Applications, Components are associated to a Domain.

• Component Base Version : Objects within Ortelius that contain the files and procedures deployed to Endpoints.

• Component Version : A child of the Component Base Version that represents changes.

A Component Object has the following properties:

Property	Description
id	A unique identifier for the Component as used in the database.
name	The name of the Component.
fqdomain	Fully qualified Domain name.
summary	Description of the Component.
domain	Domain in which the Component is contained.
owner	User or UserGroup that owns the Component.
parent	The Base Component.
predecessor	The version on which this is based.
items	The items that make up this Component.
servers	The Endpoints to which this Component has been deployed.
requests	The change requests associated with this Component .
lastbuild	The last build number for this Component, 0 if never built.
creator	The User who created this Component.
modifier	The User who last modified this Component.
ctime	The date/time the Component was created.
mtime	The date/time the Component was last modified.
Key Value Configurations	Key Value Pairs for managing associative arrays.

Component and Application Relationships

There is a many-to-many relationship between Applications and Components. An Application can contain many different Components, and a Component can be used across many different Applications. Components can be easily shared between Applications. Ortelius tracks and versions the Component relationships including to which Applications they have been assigned.

Component and Application Versioning

A backend versioning engine tracks all software deployment configurations. This is done within an Application. An Application consists of one or more Components. Versioning tracks all changes in both your Application and Component attributes.

When you first define your Application, you create an Application Base Version. Over time, as you update your code and deliver new features, each change to the Application creates a new Application Version. Application Versions package all your Components in your entire software product. Like Application Versions, there is an initial Component Base Version and subsequent Component Versions, which represent any updates . An Application Base Version or Component Base Version is always the first one created, and it acts as a model for subsequent Application or Component Versions. Otherwise they are identical types of objects.

When a new Application Version is created from either an Application Base Version or another Application Version, it inherits all previous Components from its predecessor. That predecessor is determined when running a Create Version Task for an Application Version. You can specify whether the new Application Version inherits its Components from the original Application Base Version, the latest Application Version, or a specific Application Version.

Ortelius uses a simple versioning number schema starting at 1 and incrementing over time, for example Myapp;1, Myapp;2.

You can use your CI/CD process to include variance in your versioning number (base name, variant, version). See Component Versioning Schema.

Date Object

Dates track the date/time of the creation, deletion, or update of an Object.

The Date has the following properties:

Property	Description
to_int(secs)	Returns an integer representing the date as the number of seconds since midnight on January 1st 1970 (epoch). The secs parameter is optional. If needed, the specified number of seconds is added to the date/time before the new value is returned.
to_char(fmt)	Formats the date into a string given by the passed fmt string. The fmt string should contain characters as specified below.

Domain Object

The Domain Object represents the highest order of organization for managing Applications, Components and Environments. Domains are hierarchical and can have Subdomains. Subdomains inherit the parents properties, Tasks and access.

Your microservices, a type of Component, are cataloged based on Domains and Subdomains which you define. Domains catalog microservices that solve the same ‘problem sets.’ In a similar way, Applications are assigned to their own Domain. Environments and Endpoints are associated to Domains that are managing Applications. The highest level Domain is your Global Domain.

Domains also include Tasks. Tasks include Move, Approve, Version and Deploy. Tasks can be called by external solutions via APIs for integration into your Continuous Delivery Pipeline. Tasks are associated to any Domain and can be defined as Pre or Post. Tasks are normally defined to Life Cycle Subdomains and support continuous configuration management in your continuous delivery process.

Life Cycle Subdomains allow you to automate the push of your continuous deployments from development through production. Ortelius can be called by your Continuous Delivery engine (Jenkins, Bamboo, GitLab, CircleCI, Puppet Relay, Google CloudBuild or GitHub Actions) to perform the continuous deployment task across all states of your pipeline. If you are not using a Continuous Delivery orchestration engine, you can assign Tasks to your Life Cycle Subdomain to define a continuous deployment ‘promotion’ process within Ortelius.

The following properties can be accessed on the Domain object:

Property	Description
id	Domain id, as used in the database.
name	Domain name.
fqdomain	Fully qualified Domain name.
summary	Summary text.
domain	Higher level Domain to which it belongs.
subdomains	List of Domain objects which are contained within it.
Life Cycle	A Domain that includes a pipeline and the lowest level Subdomains. Life Cycle-domains cannot have Subdomains.
Applications	The Application objects which are contained within it.
Environments	The Environment objects which are contained within it.
creator	The User or Group Object representing the user who created it.
modifier	The User or Group Object representing the user who last modified it.
ctime	Date Object representing the date/time it was created.
mtime	Date Object representing the date/time it was last modified.
owner	User or Group Objects that owns it.

Environment Object

The Environment Object represents a collection of Endpoints where an Application is deployed. Multiple Environments can represent your pipeline stages such as Development, Testing, and Production for a single Application. Your Application can have as many Envrionments as needed.

The following properties can be accessed for an Environment object:

Property	Description
id	Unique identifier as used in the database.
name	Environment name.
fqdomain	Fully qualified Domain name.
summary	Description of the Environment.
domain	Domain in which it is contained.
owner	User or Group Objects that owns it.
basedir	Base directory for deployments.
Endpoints	The Endpoints assigned to it.
Applications	The Applications associated to it.
creator	The User or Group who created it.
modifier	The User or Group who last modified it.
ctime	The date/time it was created.
mtime	The date/time it was last modified.
parent	Parent Domain.

Endpoint Object

The Endpoint Object (Local Helm Host, container, VM/Cloud Image) represents where a deployment will be sent. Endpoints are assigned to an Environment.

Endpoint Mapping

Each Component is assigned a Type attribute. You can specify which kind of Endpoint is needed. For example, a Database Component is installed onto an Endpoint with a corresponding Database Type definition. A Component is assigned a single Type, while an Endpoint can be assigned multiple Types. For example, if your single Endpoint needed to have both a database and your application binaries installed, it would be assigned both a ‘Database’ and a ‘Binary’ Type attribute.

To map a Component to Endpoints, assign one or more Component Types to each Endpoint. Then assign a single Type attribute to that Component. When an Application is deployed, each Component within the Application will be deployed to each Endpoint if the Component’s Type attribute matches one of the Endpoint’s Type attributes. Ortelius ships with standard Component and Endpoint Types and allows you to define custom Type attributes.

The Endpoint object has the following properties:

Property	Description
id	A unique identifier as used in the database.
name	The Endpoint name.
fqdomain	Fully qualified Domain name.
summary	Description of the Endpoint.
domain	Domain in which it is contained.
owner	User or Group that owns it.
hostname	Hostname (if set) or name otherwise.
basedir	Base Directory for Deployments.
type	Endpoint Type, ie: cluster, windows, cloud, etc.
Components	The Components currently installed on it.
creator	The User or Group who created it.
modifier	The User or Group who last modified it.
ctime	The date/time it was created.
mtime	The date/time it was last modified.
Key Value Configurations	Key Value Pairs for managing associative arrays.

User Object

The User Object represents a User in Ortelius. It has the following properties:

Property	Return Type	Description
id	Integer	User id, as used in the database.
name	String	User Name.
kind	String	Returns “user”. Used to differentiate between users and groups when retrieving an owner object.
fqdomain	String	Fully qualified Domain name.
realname	String	The User’s full name.
email	String	The User’s email address.
phone	String	The User’s telephone number.
groups	Array	Array of Group Objects to which this User belongs.
lastlogin	Date	The date/time last logged into Ortelius.
creator	User	User or Group Object representing who created this User.
modifier	User	User or Group Object representing who last modified this User.
ctime	Date	Date Object representing the date/time the User was created.
mtime	Date	Date Object representing the date/time the User was last modified.
owner	Object	User or Group that owns the User

Group Object

You can have two Groups which users can be assigned: Users and Administrators.

The Group Object has the following properties:

Property	Description
id	A unique identifier as used in the database.
name	Group Name.
kind	Identifies whether this is a User or a Group.
fqdomain	Fully qualified Domain name.
email	The Group’s email address.
creator	User or Group Object representing who created this Group.
modifier	User or Group Object representing who last modified this Group.
ctime	Date Object representing the date/time it was created.
mtime	Date Object representing the date/time it was last modified.
owner	User or Group that owns the object.