Components

Components are what make OpsLevel a truly extensible Software Catalog. They allow you to track, standardize best practices against, and relate any object in your software catalog.

🚧

Components are currently in Alpha.

Components have been released to new accounts and earlier adopters to gather feedback before being made Generally Available. If you wish to enable components on your account, please talk to your customer service representative or reach out to [email protected].

Getting Started with Components

To get started with Components, you must first define a Component Type in OpsLevel. You can do this directly from OpsLevel's UI. This can be done by using the navigation menu Settings > Component Types.

Every account comes with a default Component Type of Service. This Type cannot be deleted or have its name changed.

To define a new component type, select + New Component Type.

Component Types contain 3 pieces of information:

Display Name: The name of the property users will see when navigating around the OpsLevel UI.
Identifier: The unique identifier used to identify the component type from our API, tools, opslevel.yml, etc. Note: The Identifier is auto generated based on the Display Name but can be changed.
Description: Helper text that will provide more context into what this Component Type is used to track in your software catalog.

After filling out the required fields and adding a description, press Save to create a Component Type definition.

Once your new Component type is defined, you will be navigated to the Component Edit Page. From here you can see the Default Properties applied to your component and a place to define new Custom Properties.

To learn more about Custom Properties and how to define them, refer to our Custom Properties documentation.

Changing Types

A component's type can be modified from the UI the same as any other component field in OpsLevel.

Warning:Since component types are tied to a specific set of property definitions, they should be changed with care. When re-assigning a property type:

• All default property values will remain the same
• All custom property value assignments will be lost, except those that have a matching property definition on both the old and new type.

To facilitate component type migrations, the entire property diff can be seen on the UI before saving changes to a component's type. Here's an example:

Here, we can see "Mobile App" has 5 properties on the left, while "Library" has only 2. All Mobile App properties that don't have a matching definition on library will be permanently lost on updating the component type. These are marked in red, i.e. device_compatibility, last_update, platform, and release_date. Library has a new property definition for eol, seen in green, which will be set initially as null. Finally, both types have a definition for version, so that value assignment will be left in tact.

To avoid accidental destruction of custom property assignments, OpsLevel restricts the ability to change a component's type using an API key or via opslevel.yml config changes. If modifying component types using a yaml config is important to you, please contact your account representative and we can enable it on your account.

Tooling Support (coming soon)

🚧

Component Types are currently in Alpha and does not have full tooling support.

You can define, edit, and create new component types through the API.

opslevel.yml, Terraform, and CLI support coming soon...