The Split Feature Experimentation Platform brings together the world of software deployment and release with analytics to measure the impact of features and code changes. On the DevOps side of that equation, a fundamental result is that Split separates code deployment from feature release. Essentially, Split is abstracting out the logic from your code to designate which of your users will see a new feature. Or, which users will see a certain version of a new feature, what we call a Treatment.
Given that you are constantly building and rolling out new features, the control panel interface to define a feature roll-out plan becomes a key component in your workflow. It needs to be quick to configure your ordinary phased rollouts, yet intuitive in supporting much more sophisticated user targeting when needed.
To support this dual goal better than ever, our product and engineering teams recently did a deep dive with our customers to understand how they used the current Split editor. We discovered several ways that the editor could be improved to save customers time and make it easier to use.
We are excited that the following enhancements are now live on the Split Management Console:
The Split editor now automatically color-codes each treatment of a feature. The color codes are used throughout the editor and will be used in other areas of the management console as well. This provides you with an easy visual to see how a treatment is being rolled out and the impact of that roll-out on metrics.
Whitelists as Needed
Whitelists are an easy way to assign some users or a segment of users (e.g. employees or beta users) to a treatment. However, if you have several treatments, you don’t necessarily want to have to scroll through a bunch of blank whitelist fields if they are not needed.
The new editor gives you the option to add as many whitelists as you need and apply them to the applicable treatment.
Advanced Capabilities Hidden by Default
If you run a large scale app or are using Split for robust experimentation, you may want to scope down the overall set of users that are included in an experiment with the Traffic Allocation configuration. It’s a powerful feature.
Advanced targeting rules are needed by almost every Split customer, but they might not be needed for every feature roll-out.
Traffic Allocation is hidden by default and Targeting Rules can be added as needed. However, they remain easy to access and configure.
Easy, Intuitive Default Rule Setting
The UI for configuring a default rule is easier to interpret than ever, using the same color coding of treatments from the top of the editor page. And, with the more advanced features hidden by default, a developer or product manager can quickly create a basic Split with a simple percentage-based roll-out.
Overall, the interface has gotten faster and easier to use. One thing we did preserve is the logical flow of the page. A rollout plan executes in the order that elements appear on the page, i.e. top to bottom. This gives you confidence in what your users are going to experience as you configure a Split.
Try it out, and let us know what you think. If you don’t have a Split account yet, sign up for our free 14-day trial.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Audit logs make it easy to stay compliant and find feature flag changes made by your team. We’ve now made it easy to diff, comment, and find your logs.
APM tools are great at monitoring your app, but they struggle to find errors in features post-release. Feature Monitoring helps you find the root cause.