CloudServices/SoftRelease: Difference between revisions
Tarek.ziade (talk | contribs) No edit summary |
(minor edits) |
||
Line 1: | Line 1: | ||
The ''SoftRelease'' service offers a way to activate/degrade a new feature to a subset of Firefox | = Overview = | ||
The ''SoftRelease'' service offers a way to activate/degrade a new feature to a subset of Firefox Mobile / Desktop users. | |||
It's useful when the client side of your application goes through a release cycle that makes it painful | 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 | to ship experimental features or to throttle the load of a new feature. Typically Firefox Desktop & Firefox Mobile. | ||
Use cases examples: | Use cases examples: |
Revision as of 21:38, 11 December 2014
Overview
The SoftRelease service offers a way to activate/degrade a new feature to a subset of Firefox Mobile / Desktop 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 Mobile.
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:
- . We add a new "campaign-button-color" feature via the dashboard
- . we add the two possible responses:
Green => {'color': 'green'}
Blue => {'color': 'blue'}
- . 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