I'm moving old posts here. This was was posted March 1, 2023

In thinking about how to build out OpenContext we debated between starting with auto-discovery or YAML. Brian, our CEO always says, discovery is hard. He’s not wrong. It’s also where we started.

Ultimately, we wanted a product that folks could have up and running with a portion of their team and code in a matter of minutes. How else do you prove your value? Listen, I did the infrastructure as code, walking folks through how to use Git, and helping folks find the smallest piece of infrastructure they could automate until they had most of it automated. DevOps folks know how to do this, it’s in their DNA.

So let’s walk through why we decided to build a DevOps tool that starts with auto-discovery for Git, specifically starting with GitHub.

Git Your Insights Through Auto-Discovery

The OpenContext team has spent a lot of time thinking about what is and what isn’t DevOps, further, how we become a value add. More specifically, what is the next level of automation the industry needs in order to move us forward?

To keep building more and more complex products to solve more complex problems we need the context to know what we have, what’s in flight, and those things we didn’t know we had. We all know there are unknowns in our technical stack. We build products by piecing together Open Source, custom code, leveraging templates, and a decent amount of glue to make these work together seamlessly. This creates some unknown unknowns.

Why It’s Time for the Next level of DevOps Automation

I’ve spent a lot of time running Emily Freeman’s 2021 GitHub Universe talk “Rethinking the SDLC” around in my mind, if you haven’t watched it, I’d highly recommend taking the time. It brings up some great points namely, it’s time to evolve how we think about delivering software. We/I wholeheartedly agree.

That notion is really the crux of why we started with auto-discovery. Do you really need to guess what’s in Git? How accurate is that going to be? Are you doing GitOps? If so, now you have even more complexity in Git. You have all the code and infrastructure that you’ve painstakingly moved to a centralized repository. This can be powerful for you but even more powerful if you can automatically graph all that data out.

Alice our CTO talks about this in her blog post, “How to Map Your Dependency Graph in OpenContext” where she says,

If you are a GitOps shop, you are one and done. This will help you understand who is working on what. If Johnny is working on five projects but only assigned to one, why is Johnny doing this? That’s up to you to find out. (In our experience, Johnny wasn’t able to off-board from older projects and is your secret SME.)
This is where the next level of automation comes in. You’ve done the work, you’ve been doing the work by using source control for your code and maybe even your infrastructure or cloud setup. What you need now is insight, and observability more specifically you need Context for your Insight and Observability.

Context to Help Every One of Your -Ilities

GitHub is a great tool for version control. It does well with CI/CD through GitHub Actions. What it doesn’t do well is surface critical insights to the end user about who is working on what. For example, if you have one random template leveraging a language with critical vulnerabilities, how do you find it today?

What we don’t want to do is prevent folks from finding ways to move faster, in a logical and consistent way. I get it, Audrey, our Staff Engineer, and Alice joke, they are the masters of manually doing the thing twice and writing a bash script the third time. It’s what we do in Ops. It’s part of our superpower. In doing this though, we’ve added some complexity that is hidden. Hidden from Security, hidden from Ops, hidden from Devs. This makes troubleshooting harder.

What does this have to do with Git? Everything.

We do auto-discovery in Git so you can track your code paths. This means we don’t care if you have a monolith, services, or something in between. We can show you per code path/service, who is the CODEOWNER, Contributors, languages, and the last three releases. All at a glance. Not only that but we use a graph to show you just how tangled that code is.

Your Infrastructure and Code are very Jeremy Bearemy

Nothing is a straight line from here to there. That’s ok, we get that. You live that, we live it too. Being able to see that one team can break another team's code before it happens is POWERFUL. All the ilities that Emily talked about, well this is what they look like. We are surfacing those ilities from Git using Auto-Discovery from:

• Repository to code path
• Code Owners to contributors
• GitHub Actions
• Dependabot In the future, we will even have a way to surface your GitHub templates. Creating that one-stop shop to help keep Devs moving quickly and safely. Letting Security help define what is safe for the team and organization and maybe more importantly, letting them verify. Letting our Ops friends understand which release, Repo, Codepath, needs attention while surfacing who to reach out to.

Automation to move the industry forward

One of my favorite memories as a Product Manager at Puppet was the Ops team explaining, “I get bored if there aren’t fires now and again.” It always felt like they were saying the quiet part out loud but it really shaped how I do Product for DevOps folks and is a driving force for how we are building OpenContext.

Let us automate the easy bits from Git via auto-discovery. Let’s surface all that rich data in a usable fashion so both Devs and Ops can have a little more insight and empathy into what each other is working on. Let Devs, Security, and Ops, keep building those complex products for the complex problems we face today and in the future.