Sentry Beats the Support Ticket with Early Application Release Monitoring
“When viewing a website, a customer doesn’t care whether the button they clicked isn’t working because of an error or because of inefficient code that is lagging,” Desai told The New Stack. “However, to address these issues, developers need depth and consistency in information about their code health that is extremely difficult to acquire. The problems magnify exponentially when they’re doing continuous or frequent code releases.”
At the same time, Desai described how traditionally, organizations tend to invest heavily in extensive release management processes with dedicated teams to monitor several different inputs and metrics to “make sure a release is going well.”
“They look for spikes in support tickets around the same time as a release, systems, business metrics, including active users, login, revenue, etc. This is time-consuming and very reactive,” Desai said “Also, a general response to any signal that a release might be bad is to roll back a release because ‘what’s wrong?’ and ‘for whom?,’ are still unknown. If someone feels a release is bad they have no choice but to accommodate the lowest common denominator because they don’t have data to support any other decision.”
At the same time, Desai described how engineering teams often deliver digital services and applications across a number of different platforms, including web, mobile and native applications. “Maintaining a seamless, reliable user experience across all these disparate platforms is both difficult and critical,” Desai said.
Desai also noted how solving code issues often requires linking frontend issues with backend code, third-party APIs, or microservices, “which means tools that don’t fully trace issues or provide full context aren’t really solving the crash or performance issue.”
Sentry is a sponsor of The New Stack.