CloudServices/SoftRelease

The SoftRelease service offers a way to activate/degrade a new feature to a subset of Firefox OS / Firefox users.

It's useful when the client side of your application goes through a release cycle that makes it painful to ship experimental features or to throttle the load of a new feature. Typically Firefox Desktop & Firefox OS.

Use cases examples:

• ramping up Firefox Hello for our user base by making it accessible to 10% of the user base and growing it to 100% once we are confident that the server infrastructure works well.
• activating a new feature for specific regions in Firefox.
• making small UI variations like what they're doing at the Foundation for end of year campaign, see https://fundraising.mozilla.org/testing-testing-and-more-testing/

General Principle

When the client starts (Firefox OS, Firefox or a WebApp), it sends a request to the SoftRelease service to ask if a feature has to be activated or not.

The proposed API is a single HTTP endpoint that contains the name of the feature:

GET https://features.services.mozilla.com/<feature_name>

{'enabled': true}

The server analyzes the client IP and specific headers like the User Agent, and returns a JSON mapping containing the answer.

When the enabled key is sent back, the client gets a YES/NO answer and acts upon it. For example, for Firefox HELLO, the decision to display the Hello button or not could be done by this call:

GET https://features.services.mozilla.com/hello

In some other cases, the feature is activated but we want to make different versions. it's preferrable to let the client decide what to do, given a list of options values sent back by the server.

For example, in a campaign page, an UI has a button with two options that may vary amongst users: its color and its text. The client can call the server to get back the values to use:

GET https://features.services.mozilla.com/campaign-2015

{'color': '#ff0000',
 'value': 'Click Here'}

When the client wants to get several features at once, it can batch its requests by calling the root endpoint:

GET https://features.services.mozilla.com?features=campaign-2015,hello

{
 'hello': {'enabled': true}, 
 'campaign-2015': {'color': '#ff0000', 'value': 'Click Here'}
}

Dashboard

To manage the responses, the service provides a dashboard where admins can:

• add or remove a feature name
• list the different possible responses that can be returned to a user
• configure a policy for the server to decide which response to return

We provide 3 policies

• Weighted: defines a percentage for each possible response.
• Geolocation: associates regions to possible responses.
• User-Agent: associates User-Agents to possible responses.

Policies can be combined.

Example

We want to try out a new donation campaign UI for French users. In their case, we want to set the color of the button Green. For other users, we want a Blue color.

steps:

1. . We add a new "campaign-button-color" feature via the dashboard
2. . we add the two possible responses:

  Green => {'color': 'green'}
  

  Blue => {'color': 'blue'}
  

1. . we associate each response to a Geolocation Policy

  France: Green
  

  default: Blue
  

Metrics

Collecting metrics during A/B testing is mandatory to follow & understand what's the impact of the different versions of a feature.

XXX