Service cataloging 102: How to build your catalog

Now that you know the basics of what goes into a catalog, you’re ready to create your catalog—no matter where you’re starting. Populating your service catalog now is the first step in harnessing OpsLevel’s full power later on. So let’s get started!

How to add services to your catalog, fast

Below are several different ways you can import and build out your initial catalog, along with suggestions of who should use them. This blog post also outlines more pros and cons of each method to help you decide.

1. Service Detection or Kubernetes syncer

Who is it for?

Teams with an integrated git forge; teams using Kubernetes 

How it works

Our Service Detection feature is the fastest, easiest way to get started—no YAML files necessary. Just integrate your git provider, and it will automatically start flagging services based on what’s in your repos. Then you can accept or ignore the services listed on the Detected Services page. 

For organizations using Kubernetes, our Kubernetes syncer functions similarly. You can use the Syncer on a one-time basis to push data into OpsLevel or complete a single mapping exercise so it knows what to flag with each new deploy.

2. YAML files

Who is it for?

Teams who want to retain git-based dev flows

How it works

This route takes a config-as-code approach by having developers add an OpsLevel YAML manifest file to any repo. OpsLevel detects the file and pulls in data from the associated repo, and registers services into the catalog. OpsLevel automatically syncs and updates these files whenever they change.

3. GraphQL API

Who is it for? 

Teams with rich operations data models; teams with an existing catalog baseline

How it works

Our GraphQL API integrates OpsLevel with your other operations tools like Terraform, Chef, Circle CI, etc. to keep services and metadata automatically up to date, or sets OpsLevel as the source of truth. The GraphQL query language also lets you specify what data you want to retrieve (not how it should be retrieved), meaning there’s only one HTTP request, and the response is customizable.

4. Terraform Provider

Who is it for?

Teams using Terraform; teams with infrastructure-as-code

How it works

For teams that live by infrastructure-as-code, the OpsLevel Terraform provider is a good option, provisioning all objects via Terraform. Using Terraform for both creation and cataloging ensures that nothing is missed. Plus it means you don’t have to nag anyone to get their services entered. Naming and ownership conventions defined in Terraform can construct the metadata that goes into OpsLevel.

5. Import a spreadsheet

Who is it for?

If no other options worked

How it works

Make a copy of our import template, fill out the details, and share it with your CSM—we'll take care of the rest.

Maintaining catalog entries

With most of the options above, OpsLevel automatically detects new services coming in and flags them so you can decide where to map them. This helps you grow your catalog with no extra work. 

Decide your source of truth

A useful catalog is complete, accurate, and always up-to-date, so it’s important to understand where your source of truth lies.

If it’s your catalog, this establishes a “you built it, you own it” culture where each teammate is responsible for keeping their services updated in the catalog. If your production instance is the source of truth, this ensures your catalog is always automatically updated from your production reality while avoiding permissions hindrances. But if the dev portal gets deleted, this can cause problems.

Ultimately this decision is based on your engineering organization’s culture, so there’s no wrong answer—other than not being clear about your source of truth.

Now you’re ready to choose your strategy to add your first set of catalog entries and start building your catalog! Our 103 article will explain how to invite teams and users, and how they fit into the catalog structure.