So, OpsLevel is cool and all, but you know what’s not cool? Clicking around in a UI whenever you want to change some of the properties of a service.
Well click no longer! Now, with our Git Repository Integration, all you need to do is to plunk down an
opslevel.yml file at the root of one of your repositories and OpsLevel will use that to populate the corresponding service on OpsLevel’s side. (If the repository isn’t already mapped to a service, OpsLevel will create a new one.)
Keeping your service metadata up to date is now as simple as making a pull request. And making service changes integrates nicely into your existing developer workflows: e.g. transferring service ownership to another team is probably something that should go through a code review anyhow.
At the root of it (get it?) is an opslevel.yml file. It is in YAML format and should contain all the metadata that OpsLevel is tracking for this service.
Example opslevel.yml file
version: 1 service: name: Shopping Cart Service owner: order_management_team tier: tier_1 lifecycle: beta product: Retail Website language: Ruby framework: Rails description: Allows users to add/remove products in their virtual shopping carts prior to placing an order.
Frequently Asked Questions
How do I reference a specific team? (Or tier, lifecycle stage, etc?)
Notice how - in the example above - the ‘owner’ field, for instance, isn’t the name of an actual team, but some sort of identifier? You can find that identifier as the slug in the OpsLevel URL for that team.
So, for example, the OpsLevel URL of the Order Management Team is:
That last bit -
order_management_team - is the slug for this team and is what you can use as the identifier in your opslevel.yml file.
The identifiers for tiers will show up in the Service Tiers table in your Account Settings. Similar with lifecycle stages.
Will the team identifier/slug change when I change the team name?
Yes, but the old identifier will still work. Same with tiers and lifecycle stages.
Where do I put the opslevel.yml file?
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 the YAML file in the subfolder that represents your service. This should be the same path that you added to your service’s Operations Center. OpsLevel won’t create new services in the case of a monorepo; you’ll need to create the service in OpsLevel yourself. See the next question.)
What if I’ve already created a service in OpsLevel, but want to manage it with opslevel.yml going forward?
Before adding the YAML file to this service’s repo, make sure that the service in question is already mapped to this repo through the service’s Operations Center. That way, when OpsLevel detects the new opslevel.yml file, it won’t create a new service but simply update the existing one.
What if I have more questions? Ones I haven’t even thought of yet??
Just send us an email at email@example.com.