When we speak to our customers, one of the most common reasons they say they made the move towards feature flags was the need to make sure their releases didn’t cause more errors for their users. By leveraging feature flags to ramp the release of their features to just small subsets of their users at first, they’re able to see more easily if there is any impact on internal and friendly beta users before starting a larger rollout. However, this becomes a much tougher problem at scale as they struggled to closely watch for errors across all their customers at once. In other words, the issue came down to the fact that the power of ramped rollouts with feature flags was incomplete without the ability to match the error data from their users with the variant of the feature that each user was served.
An Exception-al Integration with Sentry
To that end, we’re excited to announce today the release of a new integration with Sentry to bring their error data directly into Split. Developers use Sentry to capture and process exceptions in the code, exceptions that often reveal user-facing errors. We have been using Sentry internally at Split for quite a while and love how simple it is to have a central place where we can capture the errors that occur across every level of our stack.
Sentry has SDKs in over ten different languages that will automatically listen for and capture errors occurring on a website, service, or mobile app. In addition, Sentry has powerful grouping algorithms to automatically group together similar errors to make it easier to find root cause and debug quickly.
Finding the errors in your latest release
With this integration with Sentry, our customers will now be able to automatically send all exceptions that Sentry captures across the stack directly to Split, to be used with our Impressions. This will allow our customers to define metrics in Split such as the average number of errors that each user is experiencing and have that metric measured automatically across every feature they roll out as well as define alert policies to be notified if error rates increase. Split will compare the features each user is exposed to with the errors each user hits in order to determine which feature in your release is good, and which is rotten.
By measuring these metrics in Split, our customers will now be able to get automatic feedback whenever a feature that has been released, for example, to just five percent of their user base, is causing a degradation for that small subset of users. We’re excited to see the impact this integration has for our customers and their ability to truly measure and mitigate the risk tied to any feature release.
Getting started with Split and Sentry
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
We all know a good digital experience from a bad one. Great digital experiences make our lives easier, and negative experiences drive us, and our business, elsewhere. What many users don’t realize is how difficult it is for product and engineering teams to know that the features they’re building will…
Feature flags provide so much for software organizations: they allow teams to separate code deployment from feature release, test in production, run experiments, and more. However, some rules apply to the feature flagging process that are easy for teams to overlook. I’ve gathered the best practices of feature flags from…
Continuous integration, continuous delivery, and continuous deployment are foundational in today’s agile engineering ecosystem. However, many times they are used interchangeably and often incorrectly. Let’s remove the confusion and settle the differences between continuous integration, continuous delivery, and continuous deployment. What is Continuous Integration? Continuous integration happens when developers regularly…