In addition to defining services through OpsLevel’s UI and GraphQL API, you can also utilize config as code. Leveraging our Git Repository Integrations, you can place an
opslevel.yml in a repo and OpsLevel will automatically sync its contents. You can use
opslevel.yml to track metadata about both services and repositories. This lets service and repo owners use their existing Git based development workflow to keep this metadata up to date: edit, commit, review, merge.
opslevel.yml uses human readable identifiers to specify the owner, tier, and lifecycle stage of a service. For example, an
opslevel.yml that specifies the team that owns a service looks like:
service: name: Order Processor owner: orders_team
orders_team is an alias. Aliases are automatically generated by OpsLevel for teams, tiers, and lifecycles.
Navigate to a Team page. There you can find the team alias.
Navigate to the Account page. From there you will see a list of all your Service Tiers and their aliases.
Similar to Service Tier, navigate to the Account page. From there you will see a list of all you Service Lifecycles and their aliases.
Aliases are stable identifiers. If you rename an entity that has an alias (e.g., a team), OpsLevel will generate a new alias. However, the old alias will still be valid so any existing references to it from other
opslevel.yml files will continue to work.
If you have a service already defined in OpsLevel and want it to be managed with
opslevel.yml, first ensure the service is already connected to a repo. When a service is connected to a repo, OpsLevel will know how to merge a newly detected
opslevel.yml with the service. After the repo is connected to the service, you can download the service’s YAML file and commit it to the repo.
Step 1: Visit a service’s Operation tab and select the repository your service lives in from the Repository Center by clicking Edit and + Add Repository.
Step 2: From the service page click the Download YAML button.
Step 3: Copy or Download the YAML and commit to the repo you selected in Step 1.
The following tables provide an in depth list of all the properties supported by
|name||true||The name of the service.|
|description||false||The service description.|
|owner||false||The owner of the service. Must provide a valid team alias. Please refer to the Aliases section for more details.|
|lifecycle||false||The lifecycle the service is currently in. Must provide a valid lifecycle alias. Please refer to the Aliases section for more details.|
|tier||false||The tier of the service. Must provide a valid tier alias. Please refer to the Aliases section for more details.|
|product||false||The product the service belongs to.|
|language||false||The core language the service is written in.|
|framework||false||The core framework used for the service.|
|aliases||false||A list of all user defined aliases for this service.|
|tags||false||A list of all key value tags defined for this service. Please refer to Tags section below for more details.|
|tools||false||A list of all tools used by this service. Please refer to Tools section below for more details.|
|repositories||false||A list of all repositories associated with this service. Please refer to Repository section below for more details.|
|key||true||The tag key.|
|value||true||The tag value.|
|category||true||The category the tool belongs to. Valid categories are
|url||true||The url pointing to the tool.|
|name||false||The display name used for the tool|
|environment||false||The environment this tool is used in. ex. Production, Staging.|
|name||true||The repository name.|
|provider||true||The git provider where your repository is stored.|
|display_name||false||The repository name displayed on the service page.|
|path||false||The path repository containing the opslevel.yml and where repository checks are applied. This is useful in monorepo situations where multiple services are contained in one repository.|
When a service is managed by
opslevel.yml, certain fields are locked for edit in the UI. This ensures that there is never a conflict between what’s defined in
opslevel.yml and what’s defined in the UI. A service’s name, description, owner, tier, lifecycle stage, language, and framework are all locked for edit.
Service properties that are lists, such as tools, aliases, and repositories, can have new entries added in the UI, though existing entries defined in opslevel.yml will be locked.
As shown in the image below,, to tell whether a service is managed by
opslevel.yml, you can look for a lock icon on the service’s page.
version: 1 service: name: Shopping Cart Service lifecycle: generally_available tier: tier_1 product: Retail Website owner: order_management_team language: Ruby framework: Rails description: Allows users to add/remove products in their virtual shopping carts prior to placing an order. aliases: - cart tags: - key: db value: mysql - key: kafka-topic value: cart-additions repositories: - name: DunderMifflin/shopping_cart path: "/" provider: github display_name: Cart Service Code - name: DunderMifflin/TerraformRepo path: "/production/shopping_cart" provider: bitbucket display_name: Terraform Config tools: - name: Confluence category: runbooks url: http://company.atlassian.com/confluence/runbooks - name: PagerDuty category: incidents url: https://your_account.pagerduty.com/services/PH99999 environment: Production - name: Datadog category: metrics url: https://app.datadog.com/your_dashboard?env=prod environment: Production - name: Datadog category: metrics url: https://app.datadog.com/your_dashboard?env=staging environment: Staging
Just add it to the root of your service’s repo. If this repo isn’t already mapped to a service in OpsLevel, a new service will be created.
(If you have a monorepo: just put your opslevel.yml file in the subfolder that represents your service. OpsLevel won’t discover these automatically like above, however: you’ll need to simply create a skeleton service in OpsLevel yourself and associate it with your monorepo at the subfolder in question. OpsLevel will take it from there.)
Just send us an email at email@example.com.