Skip to content

Freewheeling Feature Gate Assignments
Compare
Choose a tag to compare
@jmileham jmileham released this 24 Apr 08:51
v1.2
60cb87f
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

This marks the first release that treats feature gates differently from experiments as TestTrack begins to specialize those concepts. Conventionally, feature gates are already splits with names ending in _enabled, and with two variants - true and false. We'll begin adding split migration syntax to enforce that convention in future versions.

As of version 1.2, when the server receives a deterministic pseudorandom assignment event from a client for a feature gate (any split with a name ending in _enabled), it will ignore the event and not record the assignment. This means that unless a visitor's assignment is explicitly set to a variant (either via the chrome extension or TT admin), changes in variant weightings will instantly change the variant seen by clients in the field, even those who have already experienced that split.

Because of the way deterministic pseudorandom assignment works, every visitor in variant X at weighting = N is guaranteed to remain in that variant for weighting > N, but probabilistically will switch to variant !X as N approaches 0, providing as much continuity of user experience as possible while enabling freewheeling.

This has a couple desireable effects:

  • we can slow roll features quickly in small percentage chunks as we establish confidence in a feature's correctness, and roll them back instantly because there's no "stickiness" for feature gate assignments
  • we record less data, which reduces operational cost and bends the scale curve
Assets 2