3
minute read

How to drive code ownership in a multi-team application

June Guan

At Bugsnag, one of our main goals has always been to help you prioritize and fix the bugs that matter. The purpose of our new Alerting and Workflow Engine is exactly that.

With the new engine, you can create any set of filters in the search bar, save the set of filters as a bookmark, and use this bookmark to filter alerts in order to only receive notifications for errors that matter to you. 

In the first blog of this series, we went into detail about how to make use of the new alerting capabilities to minimize noise and deliver only alerts that are relevant and actionable. In this second blog, we will focus on how you can use the new Alerting and Workflow Engine to prioritize and fix the bugs that matter to your team.

Multiple teams working on the same application

In a large or mid-sized application, different teams will contribute to different parts of the codebase. Suppose your team is one of a dozen teams, all working together on an application that makes a mobile game. Perhaps your team works on maintaining the in-app purchases feature set, while another works on the account setup up flow, and yet another works on character customization features. The team that should be notified of a bug depends on which part of the code a bug originates from. Naturally, your team has no need for notifications about errors originating from another team’s code. 

Streamline error triaging

Bugsnag automatically reports the stacktrace, including fields such as file and method. These fields can be used to filter for code that is under the team’s code ownership, saved as a bookmark and added to a notification. Additionally, custom filters can be used to tag any error for code ownership and similarly applied to a notification. When error notifications are being sent directly to the team who owns the code, you can streamline the triaging process and save valuable time for your Release Manager, SRE or Engineering Manager, who may be triaging these errors manually today.

Learn about bugs in your team’s feature or A/B test group

Additionally, error notifications can also be useful in highlighting issues with the specific feature or A/B test group your team is working on. Custom filters can be configured based on feature flags or experiment groups which can subsequently be saved as a bookmark and associated with a notification. This will filter out the noisy alerts from parts of the application you don’t care about and make sure you are notified of every issue with the feature you’re focusing on.

Configuring alerts for your codebase

Let’s illustrate with an example of how a team can leverage notifications to be notified of only the errors in their code. 

  1. Your team creates a shared bookmark named “In-app purchase errors” which filters for specific fields (such as filenames, methods, or custom filters) that denote code owned by your team. 
  1. Configure an integration that delivers alerts to your team’s Slack channel (or any of the 40+ integrations available).
  2. Enable the “New Error” notification. Select “Advanced filter” in the configuration modal and choose the Bookmark you’ve created from the dropdown. 
  1. The next time the first event of an error matches the bookmark “In-app purchase errors”, the Slack channel alert will prompt a member of the team to investigate the new error and establish it’s priority.

Using this bookmark to filter alerts, you can ensure that the alerts you receive are relevant and actionable for your team. Once you’re aware of the bugs affecting your team without the noise of bugs that originate from another team’s codebase, you can begin to build team alignment around these bugs and prioritize them accordingly.

Stay tuned for the next blog in this series to learn about how you can leverage notifications to identify and prioritize errors affecting your most valuable customers.

Getting started

Bugsnag helps you proactively monitor and improve your software quality.