Using Ortelius with CI/CD

Integrating Ortelius into your CI/CD process.

Ortelius' Continuous Delivery And Integration

The Ortelius continuous delivery and integration performs both continuous configuration management and continuous deployments across clusters, clouds and physical data centers. The program gathers configuration data related to a build, creates new Component Versions and Application Versions, and deploys independent Components into specified Environments. “Build” data is saved as configuration information and then associated to the Component and Application.

Ortelius' uses a standard CLI Container to integrate continuous delivery solutions and execute workflows in containers. If the solution has a more traditional model, a plug-in may be required. The below list contains the CD tools Ortelius has successfully integrated with and their corresponding documentation on how each should be implemented:

CI Tool Ortelius Plugin Reference Document
Jenkins Ortelius Groovy Library Jenkins CI Plug-in
CircleCI Ortelius CircleCI Orb Ortelius Orb
Google CloudBuild Ortelius CLI Container Ortelius CLI Docker Container
GitLab Ortelius CLI Container Ortelius CLI Docker Container
TeamCity Ortelius CLI Container Ortelius CLI Docker Container

Tracking Build Updates

Ortelius' first hook into the continuous delivery process occurs after a complete build and when the container pushes to a container registry. Ortelius can support any container registry. For more details, reference the above table for for each supported solution.

Saved Build Data

Build data is saved to the Component Version and displayed on the Component Version Dashboard. In some cases, Ortelius may need to save custom data. This can be done using the Component Attributes and saved as a key/value pair. Custom data displays in the Attributes Section as Attributes to the Component Version .

The Component Type determines what data is saved. See Defining Components for a complete listing of the Detail data saved for each different Component Type.

Continuous Configuration Management and Versioning

The continuous configuration management and versioning process creates new Application Versions based on build update detection. When an update is detected, Ortelius identifies a new Component Version in the continuous delivery workflow and triggers a dependency relationship map update for all consuming Applications which creates new Application Versions.

This continuous configuration step is particularly important in a microservice implementation. Every time a new microservice is pushed across the pipeline, it impacts the configuration of the “logical” Application that consumes it. A new microservice Component creates a new Application Version. This is how Ortelius presents the Application Version Dashboard data showing the relationship and difference maps for each cluster to which the microservice Component is deployed.

Component Versioning Schema

Ortelius versions Components differently than it does new Application Versions. Components are tied to Git commits, Applications are not.

The following are the parts of the versioning schema:

Schema Description
Base name is the static part of the Component Name. For example: email-service.
Variant is a high level place holder for the versions are created within. The Variant can be aligned with a feature or branch. For example: ssl-update. Variant is not required.
Version is the schematic version number or schematic + Git commit. For example: v1.5.1.0 or v1.5.1-g3d55a2

By default, Ortelius uses an advanced format for the versioning schema. It will automatically increment the version number based on last version found. The advanced format is used since Ortelius has the information from Git to provide a complete version schema. The advanced formatting is:

 <base name>;<variant>;v<version>-g<git commit>

The version segment is broken down further into:

  v<schematic number>-<number of commits>

The number of commits provides an auto-increment of the last part of the schema number.

An example of the full name is:


Below is a breakdown of the individual parts of the versioning schema:

Part Explanation
email-service Base Name that you supply to the Ortelius Plugin for the Component.
semi colon Separator.
ssl-update Variant that you supply to the Ortelius Plugin for the Component.
semi colon Separator.
v Indicates start of the version.
1_5_1 Version that you supply to the Ortelius Plugin for the Component.
145 Number of Git Commits for the associated repository. Used for auto incrementing.
-g Separator indicating that the Git commit is next.
3d55a2 Git command SHA for the commit that triggered the CD process.

Note: The Variant is optional. That part of the Component name will be left out if the Variant passed to Ortelius by the CD workflow is blank.

Application Versioning Schema

The Ortelius continuous delivery integration will automatically maintain the Application Version if the Application Name and a starting version identifer are provided. When provided, a new Application Version will be created using the previous version identifier as a starting point. An Application Base version must exist in for Ortelius to automatically create a new Application Version when a new Component Version is created. The base version gives Ortelius the starting point to perform automatic Application versioning.

Ortelius uses a similar naming convention for Application Versions as it does for Component Versions:

Part Explanation
Base name The static part of the Application Name. For example: webstore.
Variant A high level place holder for that versions are created within. The Variant can be aligned with a feature or branch. For example: 50percent-sale. Variant is not required.
Version The schematic version number. For example, 1_2_10.

Ortelius uses the base name; schematic version number ; version number as the default format for the versioning schema. The formatting is:

<base name>;<variant>;<schematic version number>;<version number> if a Variant is used.

Deploy will automatically increment the version number based on last version found. It will create a new Application Version based on the last Application Version and replace the old Component Version with the new Component Version. The new Component Version will be added if an old verion was not found.

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

Deploying the Application Version

Once the versioning is completed, Ortelius is called to perform the deployment. The Application Version and Environment are required for the deployment. The deployment number will be returned to both Ortelius and the continuous delivery solution to be displayed in the output.

Life Cycle Tasks and Continuous Delivery Workflows

You can incorporate Ortelius' Life Cycle Subdomain Tasks as follows:


Ortelius will move the Application from one Life Cycle Subdomain to another using the Ortelius Move Task. This enables the Application to move through the same pipeline steps that the CD process is using.


If you are using DeployHub Pro, you can incorporate Approvals into your process. Ortelius will perform an Approval of an Application Move. This Approve feature is used to reflect an approval that was done in the CD Pipeline for an Application’s audit trail.

For documentation on incorporating Tasks, refer to your specific CD tool documentation as listed above.

Last modified December 18, 2020: reorganzise sections (85d5aef)