Improving Version Targeting with Split’s Regex Matchers and Feature Flags

Mobile apps today remind me of the “old” days of on-premises software.

The problem, in my opinion stems from the fact that a development team has little control as to when a user upgrades their version of the application. This means having to support multiple versions of the same functionality, the inability to sunset old endpoints, and having to worry constantly about how to tie functionality in a web application to that available in the mobile application. In short, ultimate chaos!

This problem is further exacerbated for enterprise mobile applications where an organization may not allow users to upgrade an application without permission.

At Split, we faced similar problems with our SDKs. There are two foundational components to Split’s architecture: a management console in the cloud, and an SDK that lives in our customers’ codebase. The SDK, like a mobile application is updated by the customer at their own cadence. Functionality in the management console is often tied to the version of the SDK a customer is on. Historically, we were forced to either hide a functionality from a customer who was on an older version of the SDK, or to nudge them to upgrade. Both these problems should be fairly familiar to what any mobile application developer faces even today.

Now users can to mitigate these challenges by using Split’s regular expression (Regex) matcher, that we released recently.

In this blog post, we are going to walk through how Split’s regular expression (Regex) matching capabilities can be used with a feature flag to either hide functionality, or to recommend an upgrade to a customer visiting our management console, depending on the version of SDK they are using.

Let’s focus this exercise on delivering a new “SDK Performance report” feature to customers. We’ll name this feature sdk-performance-report.

While Split supports seven different languages, let’s simplify the world down to a single SDK written in Java. The Java SDK has versions ranging from 1.0.0 to 2.0.3.

First, we will write the pseudo-code that we will put in our Javascript management console that asks Split to evaluate the feature flag and decide whether to nudge, hide, or show the performance report. See example below:

var factory = splitio({
  core: {
    authorizationKey: 'YOUR_API_KEY',
    key: 'CUSTOMER_ID',

    // we leave out how to determine the value of these attributes
    language: 'Java', // or whichever language we support
    version: '2.0.0' // or any other version number
  }
});

// And get the client instance you'll use
var client = factory.client();

client.on(client.Event.SDK_READY, function() {
  var treatment = client.getTreatment("sdk-performance-report");

  if (treatment == "show") {
    // insert code here to show the report
  } else if (treatment == "off") {
    // insert code here to hide the report
  } else if (treatment == "nudge") {
    // insert code here to show a message asking the
    // the user to upgrade their SDK
  } else {
    // insert your control treatment code here
  }
});Code language: JavaScript (javascript)

The next part focuses on setting up the sdk-performance-report feature flag in the console to return treatments based on the following rules:

Steps for setting up treatments in Split are as follows:

The default treatment is the treatment that will be served to an account if it does not match any of the targeting rules or if the Split is killed.

Let’s set up the targeting rules next. First, let’s write a rule that will capture all accounts using SDK versions >= 2.0.0. Thinking through pattern matching, it is easier to capture all SDK versions < 2.0.0 through the following rule:

The ‘version does not match “^[0-1].”’ matcher selects all accounts whose SDK version starts with any number greater than 1. That subset of customers is given the ‘show’ treatment through the bucketization ‘100% in treatment show’.

In the interest of brevity, this section will focus on a summary of a Split rollout plan that is a translation of requirements represented in the table above.

Reading this plan from top to bottom, first we see the whitelists. These can be used to hard-code a specific account to receive a specific treatment irrespective of their SDK version. In this example, we are not using whitelists.

Next, we apply the targeting rules on 100% of account traffic.

1. The first rule is the rule we previously discussed to select the subset of accounts that fall into the ‘show’ treatment.
2. The second rule selects the subset of accounts with 0 as the major version. According to Table 1, such accounts should be nudged to upgrade.
3. The third rule selects all accounts with SDK version number 1.0.x through 1.5.x. These accounts are also nudged to upgrade.
4. The last rule selects accounts with SDK version number 1.6.0 through 1.6.2. These users are also nudged to upgrade.

Any account that did not match any of the rules thus far will have an SDK version number >= 1.6.3 and < 2.0. These accounts will get the default treatment, which is named hide.

These sets of rules combined will show, hide, or nudge accounts to upgrade when they try accessing the SDK Performance Report.

Combining Matchers

We have simplified this example for one language only: Java. If support for multiple languages is required, they can be easily targeted using Split’s AND’ing capability. Here is an example:

Summary

In this blog post, we walked through an example of how each customer can be given a different experience depending on the version of product they have installed. While the driving example was Split’s own SDKs, the example is equally relevant to mobile application developers juggling with older versions of their installed apps.

While the regular expressions are a powerful way of targeting version numbers, we also understand the need for a simpler class of matchers that natively understand comparisons between version numbers. Stay tuned for improvements in this area.