Find faulty features before your customers do
One of the most common reasons that our customers move towards feature flags is risk mitigation: the need to make sure releases don’t cause errors for users. Given how frequently organizations are now deploying features, the ability to limit the blast radius of a faulty new feature becomes paramount. We found that not only do our customers want early insights into what could go wrong, but should it go wrong, they want to be able to respond to it within minutes. This means careful monitoring of feature releases, followed by alerting based on performance metrics.
One of the biggest successes we’ve had at Split in terms of customer feedback has been our ability to uniquely tie data to features. Showing different variants of a feature to different users means that every feature becomes an experiment. Tying each variant of the feature to user event data means that our customers can have early insights into the success of a feature. This in turn means greater confidence in rolling out the variant of a feature with the greatest likelihood of improving customer experience.
Tying data to features allows our customers to delight their customers better. Recently we asked ourselves what other data and functionality could enable our customers to serve their customers even better.
Introducing Feature Monitoring
For example, if your page load times get worse or your error rates rise, even for just 5% of your end users, as a result of recent change, Feature Monitoring can help you find the feature at fault before your customers do. Speaking more broadly, that means fewer rollbacks or hotfixes and greater confidence to move fast with no downtime.
We are very excited to demonstrate our Feature Monitoring solution in greater detail. Watch this space for more blog posts on each of the key features. In the meantime, here are four things you can do to go deeper today:
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
A/B testing, otherwise known as split testing, is the process of testing two different versions of a web page, feature, user flow, or other resource in order to optimize for a metric or set of metrics (often conversion rate). Multivariate tests are run with a higher number of variables and…
Which is a better approach to developing, testing, and delivering new code: feature flags, or feature branches? Can you move faster without merge hell?
The increased usage of feature flags and canary releases (also “canary deployments”) in software development has had a tremendous impact on the overall release process for software companies globally. These canaries and feature flags allow you to test your features in production , convert your monolith to microservices, perform A/B…