Sentry Release Tracking and Version Management

Sentry Release Tracking is an error-tracking web tool that provides your teams with version control and release tracking of their open-source projects. This time the integration of this tool helped us to achieve new success. Read out this case study to get an idea of what were our primary obstacles and how we overcame them.

Vikash Pathak
|
November 3, 2022
Sentry Release Tracking and Version Management

Overview / Objective

Bug tracking & fixing is one of the important jobs to maintain the software quality and when it comes to handling bugs in microservices architecture, it’s always considered one of the major pain points.

As per CISQ Report,

“On average, software developers make 100 to 150 errors for every thousand lines of code23. Of course, this number varies from developer to developer and project to project. Even if only a small fraction—say 10 percent—of these errors are serious, then a relatively small application of 20,000 lines of code will have roughly 200 serious coding errors”

There are various tools and techniques available these days for bug tracking. Sentry is one of them that is bundled with some good features.

For one of the applications (microservices architecture) designed as SaaS, we had Sentry integration in place for tracking the bugs. There were still some challenges we had like, how fast the bugs could be notified, identified & automate the process of setting up accountability to respective developers. Automating all this stuff was going to help us with providing resolution for the bugs before it impacts business for mass production users.

Challenge

For further refinement of the bug tracking process, these are the challenges we identified.

  • Track when this issue was first spotted. What were the respective changes made when that can be caused?
  • How do you set accountability for the bugs? Assign to the respective developer (who created the bug or is aware of the context) so it can be fixed a little faster.
  • Should have enough updated information about the bugs.

Solution

While brainstorming the solution with Sentry, we come to the following conclusions.

Refined Releases
Sentry provides options to define release versions. So, mapping application release versions with sentry may help us to identify which problems have been raised after which code release. Also, on the other hand, it may help to ensure the stability of release (if there are not any new bugs reported in a given period)

Link source code commits with each release
With the set-commit option, It allows associating the committees with the release. With help of this, further helps to review the recent commits and also navigate through the additional changes made with commits.

Also, linking the commit number with the release can help to define the first level of accountability for the respective developer who made the changes in the code. Generally, no one loves bugs.

Update meta information (like source map) for more visibility
For compiled or minified languages, If required meta information will be updated with each release, it helps to link the issue with a specific line of code.

Implementation

There are multiple implementation ways available for the given solution with Sentry, each may have its pros and cons. These are:-

  • Using Sentry UI
  • By using API
  • Using CLI

Creating and managing releases using Sentry UI after each deployment was a very difficult process as it required manual involvement after each release. It may only work if the release plan is not very frequent, like the application release a long ago and right now only support tasks running on and deployment frequency might be once/twice a year or so.

By using API, we may have to modify each application codebase or might need to design a common package that can be used across multiple services. Generally, the SDK could do the task but it may not update the commits or meta information correctly.

By using API
Using CLI looks good in our case as services integrated with CI/CD & it was looking easier to define a new step for sentry releases and publishing and link (place) it with existing configuration after the deployment process, so the release version should be available.
Using CLI
Further, where we had the sentry instance initialization in the application source code, must include the same version release that is defined during CI/CD deployment. So it can send all exception information with the release version.

This is how it looks after implementation:

Quick Side Access With Issue Details Page
Sentry UI

Result

It’s been about 2 years, now we have integrated it with all our services and noticed a good improvement in issues monitoring and handling. After successfully mapping the application release with the sentry, we can see the clear versioning of issues with the new tag release. Also, able to group the issues triggered after a release.