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.

opslevel.yml

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:

https://app.opslevel.com/teams/order_management_team

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 give us a shout in Slack or send us an email at info@opslevel.com.

With our Git Repository integration, OpsLevel can continuously scan your code repositories and verify all of the operational best practices you’ve defined.

Previously, we’ve shown you a Repo File Check, which can be used to verify that a given file exists in your repo, or verify that it contains some specific text.

This article goes over something subtly different and equally powerful:  a Repo Search Check.

The Repo Search Check

Instead of looking at a specific file, Repo Search Checks can be used to scan over all files in your repo to determine whether any of them contain (or do not contain) specific text.  You can also restrict the search to files of a given extension.

Repo Search Check Examples

Verify that a deprecated Scala library is no longer in use

Scala’s sbt build system is very flexible, but due to this flexibility can be hard to parse.  To be absolutely sure a deprecated package is no longer in use by any of your Scala services, you can use a Repo Search Check to look at all files.  Omit the extension for extra coverage.

When to use a Repo Search Check

Simply speaking, if you can use a Repo File Check instead of a Search Check, you should.  The Search check is much more computationally expensive to run, and is throttled on the integration’s side, so should be used sparingly.

There are some other limitations with the Repo Search Check:

• It doesn’t work with forked repositories.
• It can’t limit the search to a specific file.  If you need that, use a Repo File Check.

If you have any questions, or just come up with some interesting checks you want to share, hit us up at info@opslevel.com.

After setting up a Git Repository integration, OpsLevel can continuously scan your code repositories and verify all of the operational best practices you’ve defined.

Along with the integration comes two new checks:  the Repo File Check, and the Repo Search Check.  This article describes the former, as well as some of the cool things you can do with it.

The Repo File Check

With the Repo File Check, you can verify the existence or contents of a file in your repo.

Why would you want to do that?  Well, let’s see some examples of different kinds of checks you can build:

Repo File Check Examples

Verify Ruby version

You can verify that a repo is using a given Ruby version using either .ruby-version or Gemfile.lock. For example:

Verify Ruby library

Like verifying the Ruby version, you can look at Gemfile.lock to verify a particular library is installed.

Verify Rails is not logging passwords

Part of the Rails Security Guide talks about how to set up Rails to not log passwords. You can verify that your apps have this enabled:

Verify Python version

Much like verifying the Ruby version, if you use Pyenv, you can verify the version of Python with .python-version.

Verify Python Library

If you use pip and requirements.txt, you can validate that a given Python library version is used. Be sure to freeze your requirements beforehand with pip freeze > requirements.txt.

Verify Java library

If you use Apache Ivy, you can easily validate the presence of a given Java library.

Verify README.md exists

It’s good practice that every repo should have a README.  Just create a check that validates that this file exists, without looking into its contents.

Verify CircleCI is setup properly

If you use CircleCI, you can verify any aspect of your continuous integration. For example, you may want to verify that linting is enabled with Danger or that you’re running tests with RSpec.

Verify a recent version of Kubernetes

Older versions of Kubernetes had an apiVersion of apps/v1beta2. You can verify that your repos are all using the latest version of Kubernetes in their deployments.

And more!

Ok, those were just some examples to get the creative juices flowing.  But there’s tons more you can do with Repo file checks.  If you have any questions, or just come up with some interesting checks you want to share, hit us up at info@opslevel.com.

You likely use a myriad of cloud-based tools to operate your services.  At OpsLevel, part of our master plan is bringing various data points from all of these tools to help you gain insights and build more reliable software. We’re proud to announce our latest step on this journey with our new Github and Bitbucket integrations.

GitHub Integration

Our GitHub integration unlocks a lot of new functionality in OpsLevel:

• New checks are available that can dive deep into your codebase.  Do you want to make sure all your Python services are on a modern version of the language?  Or that no services are using an old library that you’re trying to deprecate?  Or that every service has a CircleCI config file?  You can do that.
• OpsLevel will stay up-to-date by reading the opslevel.yml files in your services’ repos.  Now you don’t have to go to OpsLevel’s UI to update your service metadata, and can make changes to service metadata using pull requests.

To set up a GitHub or Bitbucket integration, go to our Integrations tab, and hit “New Integration”. Then, look for the integration you want and hit “Add Integration.”

Follow the prompts, tie it to your organization, and OpsLevel will soon show you a list of all repositories it has access to.

Map a Repository to a Service

For the Repo-specific features to work, OpsLevel needs to know which services map to which repos.

If you’ve added an opslevel.yml file to your repo, it will automatically create a service in OpsLevel and do the mapping for you.  You can skip the below.

But if you have already created a service in OpsLevel, then you should manually map it to a specific repo.  To do this, simply add a link to your repo in that service’s Operations Center.

If found, OpsLevel will show a green pill indicating that the service is connected and that it is actively monitoring that repo.

(Note:  if you have a mono-repo, just add a link directly to the subfolder that represents your service.)

Have fun

Now you can start setting up some Repo File Checks, Repo Search Checks, and start using opslevel.yml to keep OpsLevel data up to date.

If you have any questions or are interested in trying out OpsLevel, hit us up at info@opslevel.com.

OpsLevel has become a lot more powerful with the addition of our newest features:  Checks and Checklists.

Now you can actually codify your best-practices around building and operating microservices, and then view how these practices are being followed across your entire architecture.

Checklists

A checklist is, obviously, a list of checks.  But a checklist also comes with “conditions”:  these let you define which of your services this checklist should apply to based on those services’ properties.

To create a checklist:  navigate to the Checklists tab, and click New Checklist.

Now define your checklist’s conditions.  Maybe you want to create a checklist that only runs against those services that are written in Ruby?  Or a checklist that only applies to Tier 1 and Tier 2 services?  You can do that!

Checks

Checks are the meat of your checklist.  Checks define what you want to be true with how your services are built and operated.

There are a number of different checks you can define, and most have a lot of options.  You can define a simple ownership check (to make sure none of your services are orphaned), or you can set up tool checks – that make sure your services are using certain operational tools.  You can even set up checks that dive into your codebase with our Git Repository integration.  Go ahead and create some!

Reports

Now that you have checklists defined with various checks, you can see – on your services’ detail pages – whether these checks are passing or failing for each of the particular services they apply.

But you can also get a view of your operational health across all your services with our reports feature.  Moving to Kubernetes?  Below is an example report showing all the services passing and failing a Kubernetes tool check.

If you have any questions or are interested in trying out OpsLevel, hit us up at info@opslevel.com.

OpsLevel has a feature where it allows you to define what “tier” each of your services are.

This feature has started some good conversations and encouraged many of our alpha users to ask themselves: “What tier are our services, anyway? And what’s in a tier, really?”

A service’s “tier” is an indicator of how mission-critical the service is and how tolerant your business is to the service’s downtime. The higher the tier, the more critical it is that the service remains available.

Why should an organization define availability tiers for their services?

1. First and foremost, it can be tied explicitly to the magnitude of the incident response for if/when that service goes down.  For instance, if you have a Tier-1 service, you could have its outages trigger major incidents with multiple responders and a coordinated response.
2. Secondly, there’s a lot of power in having service tiers explicitly defined with a common nomenclature: you can’t have have implicit/unspoken disagreements on a service’s availability needs if it has a clearly-defined tier. To make things even simpler, you could even have standardized SLOs per tier.
3. Finally, if your service tiers are explicit, it’s a lot easier to suss out dependency problems: there’s clearly a problem if your Tier-1 service has a hard dependency on another Tier-3 service.

You can now define all of your service tiers directly in OpsLevel.

In OpsLevel, we’ve always supported tiers as something you could set for your service. But the exact definition of a tier – and its corresponding business impact – usually differs between organizations. We now let you actually capture whatever works for you and your organization.

You can set the definitions for Service Tiers in the Account Settings page:

We’ve started by giving you some reasonable defaults, but please go ahead and customize them for your business. If you don’t have any formal tiers set up yet, this might prompt some interesting conversations with your team.

Bonus: you can also now define your services’ lifecycle stages in OpsLevel too!

A service’s “lifecycle stage” relates to what phase it is in its development. For example, when you first start building a new service, and when the features it supports aren’t yet in the hands of any of your customers, you might call the service “pre-alpha” or a “prototype”.  As things progress, and as more and more customers are using the service, it might go through phases like “alpha” and “beta” until it’s generally available to all customers. Later down the road, after many years of features and maintenance and laughter and tears, you may decide to sunset your service as a result of changing business requirements. These are all different stages in the lifecycle of most services and usually have a direct correlation to how operationally mature a given service is expected to be.

You can now configure your services in OpsLevel accordingly.  Again, we’ve set you up with some reasonable defaults in Account Settings, but please go ahead and customize their definitions for your business:

Both Service Tiers and Lifecycles are going to be instrumental in our upcoming Checks and Checklists features. Stay tuned for more from Team OpsLevel!

Feedback welcome

As always, if you have any feedback about any of our new features, please reach out to us on the OpsLevel Feedback Slack Channel or email us at info@opslevel.com.

We here at Team OpsLevel have been busy and are proud to announce our newest feature: reports.

With reports, it’s easy to see the health of your teams and services at a glance.

OpsLevel has always let you see checks on each of your services, but it was hard to see how a single check was performing across services.  Until now! 🎉

By service

With our new reports feature, you can see easily see how a given check is performing across all of your services.  For example, in the above image, we can see that the Orchestrator check is passing on three services and failing on four services.

By team

In addition to seeing a check across all of your services, you can also see how your teams are performing on adopting a given check.  For example, in the above image, we quickly see that:

• the Analytics team is crushing it (all of their services are using an orchestration tool)
• the Storage Team has yet to start (those darn Storage folks).

Additionally, clicking on the + sign beside a team will show each of that team’s services and how it’s faring with the check.

The team view gives you a concise understanding of check adoption and which teams need support.

Feedback welcome

Reports is generally available for all OpsLevel customers.  You can find it in the Reports tab in the navigation pane.

As always, if you have any feedback about reports, please reach out to us on the OpsLevel Feedback Slack Channel or email us at info@opslevel.com.