What’s New in OpenContext: Team Views Plus Integrations with PagerDuty and GitHub Actions

Today, OpenContext co-founders, Brian Walter (CEO) and Alice Chen (CTO), sit down to share how we’re answering the Who does what? question in the context of your code environment and highlighting how our integrations with PagerDuty and GitHub Actions will increase efficiency—especially when you need it most.

This article covers the following features OpenContext recently released:

• Team Views
• PagerDuty Integration
• GitHub Action Integration

Let’s dive into our co-founder Q&A!

Understand who works on what with Team Views

Up until now, OpenContext users have been able to view a page of context on the level of code components, platform components, auxiliary components, data centers, and users. Now, they’re able to look at context for Teams as well as persons. 

Walk through the Team Views and what you're most excited about?

Alice: So the Team Views give an overall high-level view of what the team is working on. The various auxiliary components, platform infrastructure components, and other code components that the team owns. 

And of those code components, we show both the different types of components, repositories, and like code paths, which means that you get an idea of how many things is this team working on. 

Often, we don't have any visibility into code paths, which is a thing, especially because those only typically show up in mono repo. A team could own multiple code paths, which means technically, they own multiple services in a mono repo of this big giant app. 

That's not it's not something that's easily highlighted or easily found. Usually, it's dependent on people knowing who to go find. What I like about this is, at a glance, somebody outside of development like in security, can look at this and say “this team owns a lot of different code paths,” or “they own a lot of different services.” So, they can get an idea of what the team's workload is or how busy they are. 

Then from there, you can also go and see if any of the repositories that they're working on have had any recent releases and what other contributors are contributing to this repository outside of the team. 

Can you share how this would be used or beneficial to a day-to-day OpenContext user?

Brian: I can take that one. As a longtime technology manager, I cannot begin to tell you how many spreadsheets I've built over the years to try to track who is on what team and what those teams own in terms of service ownership or stewardship. 

I can guarantee none of them were ever correct. 

It’s a symptom of the fact that everybody loves to help everybody in a technology organization. People have knowledge that extends beyond their assignments or the areas of the stack they are working on. It may be that they built something in the past, on another team, they changed teams or the services have been reassigned. 

So there's all of this tacit knowledge in your organization and knowing who is on a team is just scratching the surface of knowing how to get a problem solved or a question answered.

Our Team Views allow you to visualize not just who is assigned to what and who was on what team, but, when we look at those components, we can see who the last one to contribute to it was. Are they still the owner of the thing? They may not be, but they may be the person in the company that is the best source of knowledge about it. 

Through the graph view, it's crisp and clear to see who owns things. 

If you're a brand new employee going through onboarding and learning as you go and you've been assigned to go work on a particular part of the system and think you’re about to have a dependency on another thing you’re not going to have any idea who owns it. You’ll be running through questions in your head:

• How can I find an answer? 
• How do I know who those people are? 
• How do I get to them? 
• Do they have a Slack channel? 
• What's their team name? What are their names? 
• Are they halfway across the globe? 

And that's where the dependency graph view associated with teams brings us. Because usually they can find a service or repository or code path relatively easily, but then finding who owns that thing is usually the challenging part. Now, they can just look.

What problems does the team's view solve for DevOps teams who want to achieve shared context?

ALICE: You can’t actually be both the developer and the ops person, right? A lot of organizations try to smush both roles into one person or a couple of people, but, at best, the person is going to be very good at one aspect of it and mediocre at the other aspect of it. That's just not a particularly optimal use of people's time. You end up having to then rely on one person who becomes the point of failure for the entire pipeline. Context brings what both developers need to know and ops people need to know together in one location. So everyone can see everything.

BRIAN: That's right. DevOps is not a person. DevOps is sharing context and perspective across teams. That's what our tool is. 

Good fences make good neighbors. Through the Team Views, we were able to understand who owns what parts, and individuals are able to know how they are going to impact it. 

That's especially important when we think about remote work. Context sharing used to exist in an office and the team that worked together closely is happening through different channels now—Zoom, Slack, and other virtual channels. We need to have some vehicle to share that context.

The relationships between the components of your build pipeline, whether that's people, infrastructure, code, components, teams, docs, or all of these different things, they all have a relationship with each other. Modeling that relationship and making it visible empowers cross-team context, it's not a substitute for the tacit knowledge that exists in your organization. It's an enabler for it.

What are some Team View benefits for security? 

ALICE: Well, knowing releases and which teams are releasing. A new release may cause a new security incident which happens more often than people would like to admit. Often security gets paged for an incident that Ops is working on. So, with the Team Views, they can go and look up information and get up to speed faster right at the time they get called.

BRIAN: I can't tell you how many times as an engineering leader, I've experienced a security team generating a list of vulnerabilities in a complex system, you know, some of these large web properties have had just incredible nuance and incredible numbers of back end services and, and complexity to them that understanding who owns what pieces of the application and the infrastructure is really difficult. 

So when security generates this list of vulnerabilities, that gets sent over the wall to see who raises their hand. Spoiler alert: It doesn't. 

In reality, you don't get the feedback that you want. If you're a security person trying to affect change in the organization and you've got 100 vulnerabilities you're trying to follow up on and understand the context of why it’s there and what impact it has on the business, or maybe you're trying to drive an updated threat model. Either way, you need to know who the key people are in that interaction. As a security person, that's one of the most difficult things they have to do. 

It's not identifying the vulnerability. That's easy. There are great tools in that space. DependaBot, Snyk, etc. The hard part is getting them fixed because the hardest part about getting them fixed starts with who's going to fix it. 

You've got to get it to the right hands.

ALICE: And not all vulnerabilities are created equal. Priorities in the business are always changing. There's more to it. 

Get to the people, answers, and solutions you need exponentially faster with our PagerDuty integration

BRIAN: I've been that one on call. Alice has been that one on call. It can be dicey.

The pager is vibrating next to your bed. You're like, “Oh, my God, what just went wrong?” You've got an elevated heart rate. You're half asleep. The retail app is down. Okay, retail apps have never been down before. Now what? 

What is the main value of having a PagerDuty integration in OpenContext?

ALICE: With OpenContext, you simply go to the Retail App’s Context Page, and, from there, you will be able to see the platform components and who owns them. And if the team has been nice enough to give you links to their run books, you would also see those things there. 

And, on the Context Page, you'll see the PagerDuty integration with the incident in red. Then you can click through to PagerDuty to see more details about it.

Aside from troubleshooting incidents, how does integrating with PagerDuty fit into day to day life of an OpenContext user?

ALICE: The OpenContext <> PagerDuty integration also displays Change Events. So, if your developers and the CI engineer have integrated PagerDuty change events into their CI pipeline, you would be able to see that the Retail VM has dependencies. And you can go look at like the other core components such as GitHub Actions (see below), which might give you an idea of whether the issue has to do with a recent release or not. 

BRIAN: Having access to PagerDuty isn't necessarily something every engineer in your pipeline has. We'd like to see that. But they don't always. It's very common that all of the operators will have PagerDuty access, but the developers won't. And so now if I'm charged with building operable software, I and I'm the steward of a system, I want to know all the incidents and events that are happening at night because I want to improve the quality of the software I'm releasing. 

But I've never had access to PagerDuty before. 

Having that graph-based view into the incident log from PagerDuty right there in OpenContext, is hugely valuable from a developer perspective.

Do something about the red you see in your CI/CD with OpenContext + GitHub Actions

OpenContext connects with GitHub Actions dashboards to make it easy to find the info you care about for incident response as well as overall health monitoring.

Where will OpenContext users find the GitHub action integration and how does it benefit them? 

ALICE: For any code component repository, OpenContext users can find GitHub Actions on the Context Page. This will show the details of your workflows such as things like who caused the GitHub Action to run. 

At a high-level, you can see an overview of the steps each workflow takes inside of GitHub Actions for anything from a build or a deployment that you're using GitHub Actions for continuous delivery. 

Essentially, all the things you’d want to know, you can see at a quick glance. Like, if everything is failing lately, we have a big problem with this repository. Somebody needs to go and fix it pronto. Except without GitHub Actions insights you might not see that maybe it already has been fixed. You have no idea if somebody or nobody is working on it. 

So by integrating with GitHub Actions, OpenContext users get more of an idea and more insights about what's happening with their repositories, or with the repository associated with the code path.

BRIAN: I can't think about how many times a Product Manager has asked me “Hey, what's the status of that?” So, having GitHub Actions at the forefront of context is going to open up visibility outside of development to the activity that goes on within development. 

Being able to see activity, from a build perspective, is very interesting outside of development, not just in it. Ops absolutely would love to know, build activity, leading up to an incident, right?

This has been a highly asked for feature, and we're super excited about it.

ALICE: Yeah, and it's not to say that GitHub Actions will be all that interesting to every security person or every operator, but it will certainly be very interesting to other dev teams, especially in a mono repo environment where the build can impact lots of teams. 

Final thoughts on this feature release

BRIAN: We built the company around the idea that shared context across teams is the answer to so many business problems. The team's view embodies that more than any other feature we've got. You know, we're not here to target a dev team or an ops team or a security team, we're here to enable a technology team,

ALICE: You know, in my previous life, if you didn't have the right permissions or access to PagerDuty or GitHub, there was so much you couldn't see. And at big organizations and even small ones, read-only access can be too much to ask for. 

So you hope that the Wiki was up to date because everybody knows those wikis, there are several versions of them, and they're never up to date.

MELISSA: And sometimes even if you have read-only view, you still have to hunt and sift through information and data to get the thing you need.

This team has come up with a tool that pulls the exact right amount of data and puts it in the context of where people need it most so they don’t have to hunt for what they need. And that's based on the experience of the team and what our founders and engineers have been through in their careers.

BRIAN: Exactly. [OpenContext] is a team that has the scars of being through running complex operating environments, complex, large web services, and inner woven structures of documents, that are just impossible to decipher. 

That's why we're focused on getting you to the right document for your code component, the right document for your piece of infrastructure, and so on that's going to be the authoritative source. And it's going to be maintained as an artifact in the code. 

So there's always one stop for the right place to keep that document and you'll be able to find it.