Commit f3615927 authored by Alper Akgun's avatar Alper Akgun

Merge branch 'update-gitlab-experiment-to-0.7.0' into 'master'

Release gitlab-experiment version 0.7.0

See merge request gitlab-org/gitlab!79299
parents 1b777000 8e60a8ae
...@@ -489,7 +489,7 @@ gem 'flipper', '~> 0.21.0' ...@@ -489,7 +489,7 @@ gem 'flipper', '~> 0.21.0'
gem 'flipper-active_record', '~> 0.21.0' gem 'flipper-active_record', '~> 0.21.0'
gem 'flipper-active_support_cache_store', '~> 0.21.0' gem 'flipper-active_support_cache_store', '~> 0.21.0'
gem 'unleash', '~> 3.2.2' gem 'unleash', '~> 3.2.2'
gem 'gitlab-experiment', '~> 0.6.5' gem 'gitlab-experiment', '~> 0.7.0'
# Structured logging # Structured logging
gem 'lograge', '~> 0.5' gem 'lograge', '~> 0.5'
......
...@@ -460,10 +460,9 @@ GEM ...@@ -460,10 +460,9 @@ GEM
gitlab-dangerfiles (2.8.0) gitlab-dangerfiles (2.8.0)
danger (>= 8.3.1) danger (>= 8.3.1)
danger-gitlab (>= 8.0.0) danger-gitlab (>= 8.0.0)
gitlab-experiment (0.6.5) gitlab-experiment (0.7.0)
activesupport (>= 3.0) activesupport (>= 3.0)
request_store (>= 1.0) request_store (>= 1.0)
scientist (~> 1.6, >= 1.6.0)
gitlab-fog-azure-rm (1.2.0) gitlab-fog-azure-rm (1.2.0)
azure-storage-blob (~> 2.0) azure-storage-blob (~> 2.0)
azure-storage-common (~> 2.0) azure-storage-common (~> 2.0)
...@@ -640,7 +639,7 @@ GEM ...@@ -640,7 +639,7 @@ GEM
mime-types (~> 3.0) mime-types (~> 3.0)
multi_xml (>= 0.5.2) multi_xml (>= 0.5.2)
httpclient (2.8.3) httpclient (2.8.3)
i18n (1.8.11) i18n (1.9.1)
concurrent-ruby (~> 1.0) concurrent-ruby (~> 1.0)
i18n_data (0.8.0) i18n_data (0.8.0)
icalendar (2.4.1) icalendar (2.4.1)
...@@ -1035,7 +1034,7 @@ GEM ...@@ -1035,7 +1034,7 @@ GEM
declarative (< 0.1.0) declarative (< 0.1.0)
declarative-option (< 0.2.0) declarative-option (< 0.2.0)
uber (< 0.2.0) uber (< 0.2.0)
request_store (1.5.0) request_store (1.5.1)
rack (>= 1.4) rack (>= 1.4)
responders (3.0.0) responders (3.0.0)
actionpack (>= 5.0) actionpack (>= 5.0)
...@@ -1157,7 +1156,6 @@ GEM ...@@ -1157,7 +1156,6 @@ GEM
sawyer (0.8.2) sawyer (0.8.2)
addressable (>= 2.3.5) addressable (>= 2.3.5)
faraday (> 0.8, < 2.0) faraday (> 0.8, < 2.0)
scientist (1.6.2)
sd_notify (0.1.0) sd_notify (0.1.0)
securecompare (1.0.0) securecompare (1.0.0)
seed-fu (2.3.7) seed-fu (2.3.7)
...@@ -1377,7 +1375,7 @@ GEM ...@@ -1377,7 +1375,7 @@ GEM
nokogiri (~> 1.8) nokogiri (~> 1.8)
yajl-ruby (1.4.1) yajl-ruby (1.4.1)
yard (0.9.26) yard (0.9.26)
zeitwerk (2.5.3) zeitwerk (2.5.4)
PLATFORMS PLATFORMS
ruby ruby
...@@ -1470,7 +1468,7 @@ DEPENDENCIES ...@@ -1470,7 +1468,7 @@ DEPENDENCIES
github-markup (~> 1.7.0) github-markup (~> 1.7.0)
gitlab-chronic (~> 0.10.5) gitlab-chronic (~> 0.10.5)
gitlab-dangerfiles (~> 2.8.0) gitlab-dangerfiles (~> 2.8.0)
gitlab-experiment (~> 0.6.5) gitlab-experiment (~> 0.7.0)
gitlab-fog-azure-rm (~> 1.2.0) gitlab-fog-azure-rm (~> 1.2.0)
gitlab-labkit (~> 0.21.3) gitlab-labkit (~> 0.21.3)
gitlab-license (~> 2.1.0) gitlab-license (~> 2.1.0)
......
...@@ -41,10 +41,6 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp ...@@ -41,10 +41,6 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp
# define a default nil control behavior so we can omit it when not needed # define a default nil control behavior so we can omit it when not needed
end end
def track(action, **event_args)
super(action, **tracking_context.merge(event_args))
end
# TODO: remove # TODO: remove
# This is deprecated logic as of v0.6.0 and should eventually be removed, but # This is deprecated logic as of v0.6.0 and should eventually be removed, but
# needs to stay intact for actively running experiments. The new strategy # needs to stay intact for actively running experiments. The new strategy
...@@ -64,12 +60,12 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp ...@@ -64,12 +60,12 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp
private private
def tracking_context def tracking_context(event_args)
{ {
namespace: context.try(:namespace) || context.try(:group), namespace: context.try(:namespace) || context.try(:group),
project: context.try(:project), project: context.try(:project),
user: user_or_actor user: user_or_actor
}.compact || {} }.merge(event_args)
end end
def user_or_actor def user_or_actor
......
...@@ -10,6 +10,13 @@ Gitlab::Experiment.configure do |config| ...@@ -10,6 +10,13 @@ Gitlab::Experiment.configure do |config|
# #
config.base_class = 'ApplicationExperiment' config.base_class = 'ApplicationExperiment'
# Customize the logic of our default rollout, which shouldn't include
# assigning the control yet -- we specifically set it to false for now.
#
config.default_rollout = Gitlab::Experiment::Rollout::Percent.new(
include_control: false
)
# Mount the engine and middleware at a gitlab friendly style path. # Mount the engine and middleware at a gitlab friendly style path.
# #
# The middleware currently focuses only on handling redirection logic, which # The middleware currently focuses only on handling redirection logic, which
......
...@@ -4,26 +4,24 @@ group: Adoption ...@@ -4,26 +4,24 @@ group: Adoption
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
--- ---
# Implementing an A/B/n experiment using GLEX # Implementing an A/B/n experiment
## Introduction ## Introduction
`Gitlab::Experiment` (GLEX) is tightly coupled with the concepts provided by Experiments in GitLab are tightly coupled with the concepts provided by
[Feature flags in development of GitLab](../feature_flags/index.md). Here, we refer [Feature flags in development of GitLab](../feature_flags/index.md). You're strongly encouraged
to this layer as feature flags, and may also use the term Flipper, because we to read and understand the [Feature flags in development of GitLab](../feature_flags/index.md)
built our development and experiment feature flags atop it. portion of the documentation before considering running experiments. Experiments add additional
concepts which may seem confusing or advanced without understanding the underpinnings of how GitLab
You're strongly encouraged to read and understand the uses feature flags in development. One concept: experiments can be run with multiple variants,
[Feature flags in development of GitLab](../feature_flags/index.md) portion of the which are sometimes referred to as A/B/n tests.
documentation before considering running experiments. Experiments add additional
concepts which may seem confusing or advanced without understanding the underpinnings We use the [`gitlab-experiment` gem](https://gitlab.com/gitlab-org/ruby/gems/gitlab-experiment),
of how GitLab uses feature flags in development. One concept: GLEX supports sometimes referred to as GLEX, to run our experiments. The gem exists in a separate repository
experiments with multiple variants, which are sometimes referred to as A/B/n tests. so it can be shared across any GitLab property that uses Ruby. You should feel comfortable reading
the documentation on that project if you want to dig into more advanced topics or open issues. Be
The [`gitlab-experiment` project](https://gitlab.com/gitlab-org/ruby/gems/gitlab-experiment) aware that the documentation there reflects what's in the main branch and may not be the same as
exists in a separate repository, so it can be shared across any GitLab property that uses the version being used within GitLab.
Ruby. You should feel comfortable reading the documentation on that project as well
if you want to dig into more advanced topics.
## Glossary of terms ## Glossary of terms
...@@ -35,41 +33,9 @@ when communicating about experiments: ...@@ -35,41 +33,9 @@ when communicating about experiments:
- `control`: The default, or "original" code path. - `control`: The default, or "original" code path.
- `candidate`: Defines an experiment with only one code path. - `candidate`: Defines an experiment with only one code path.
- `variant(s)`: Defines an experiment with multiple code paths. - `variant(s)`: Defines an experiment with multiple code paths.
- `behaviors`: Used to reference all possible code paths of an experiment, including the control.
### How it works ## Implementing an experiment
Use this decision tree diagram to understand how GLEX works. When an experiment runs,
the following logic is executed to determine what variant should be provided,
given how the experiment has been defined and using the provided context:
```mermaid
graph TD
GP[General Pool/Population] --> Running?
Running? -->|Yes| Cached?[Cached? / Pre-segmented?]
Running? -->|No| Excluded[Control / No Tracking]
Cached? -->|No| Excluded?
Cached? -->|Yes| Cached[Cached Value]
Excluded? -->|Yes| Excluded
Excluded? -->|No| Segmented?
Segmented? -->|Yes / Cached| VariantA
Segmented? -->|No| Included?[Experiment Group?]
Included? -->|Yes| Rollout
Included? -->|No| Control
Rollout -->|Cached| VariantA
Rollout -->|Cached| VariantB
Rollout -->|Cached| VariantC
classDef included fill:#380d75,color:#ffffff,stroke:none
classDef excluded fill:#fca121,stroke:none
classDef cached fill:#2e2e2e,color:#ffffff,stroke:none
classDef default fill:#fff,stroke:#6e49cb
class VariantA,VariantB,VariantC included
class Control,Excluded excluded
class Cached cached
```
## Implement an experiment
[Examples](https://gitlab.com/gitlab-org/growth/growth/-/wikis/GLEX-Framework-code-examples) [Examples](https://gitlab.com/gitlab-org/growth/growth/-/wikis/GLEX-Framework-code-examples)
...@@ -87,9 +53,9 @@ experiment in code. An experiment implementation can be as simple as: ...@@ -87,9 +53,9 @@ experiment in code. An experiment implementation can be as simple as:
```ruby ```ruby
experiment(:pill_color, actor: current_user) do |e| experiment(:pill_color, actor: current_user) do |e|
e.use { 'control' } e.control { 'control' }
e.try(:red) { 'red' } e.variant(:red) { 'red' }
e.try(:blue) { 'blue' } e.variant(:blue) { 'blue' }
end end
``` ```
...@@ -146,11 +112,11 @@ We can also implement this experiment in a HAML file with HTML wrappings: ...@@ -146,11 +112,11 @@ We can also implement this experiment in a HAML file with HTML wrappings:
```haml ```haml
#cta-interface #cta-interface
- experiment(:pill_color, actor: current_user) do |e| - experiment(:pill_color, actor: current_user) do |e|
- e.use do - e.control do
.pill-button control .pill-button control
- e.try(:red) do - e.variant(:red) do
.pill-button.red red .pill-button.red red
- e.try(:blue) do - e.variant(:blue) do
.pill-button.blue blue .pill-button.blue blue
``` ```
...@@ -212,38 +178,30 @@ wouldn't be resolvable. ...@@ -212,38 +178,30 @@ wouldn't be resolvable.
### Advanced experimentation ### Advanced experimentation
GLEX allows for two general implementation styles: There are two ways to implement an experiment:
1. The simple experiment style described previously. 1. The simple experiment style described previously.
1. A more advanced style where an experiment class can be provided. 1. A more advanced style where an experiment class is provided.
The advanced style is handled by naming convention, and works similar to what you The advanced style is handled by naming convention, and works similar to what you
would expect in Rails. would expect in Rails.
To generate a custom experiment class that can override the defaults in To generate a custom experiment class that can override the defaults in
`ApplicationExperiment` (our base GLEX implementation), use the rails generator: `ApplicationExperiment` use the Rails generator:
```shell ```shell
rails generate gitlab:experiment pill_color control red blue rails generate gitlab:experiment pill_color control red blue
``` ```
This generates an experiment class in `app/experiments/pill_color_experiment.rb` This generates an experiment class in `app/experiments/pill_color_experiment.rb`
with the variants (or _behaviors_) we've provided to the generator. Here's an example with the _behaviors_ we've provided to the generator. Here's an example
of how that class would look after migrating the previous example into it: of how that class would look after migrating our previous example into it:
```ruby ```ruby
class PillColorExperiment < ApplicationExperiment class PillColorExperiment < ApplicationExperiment
def control_behavior control { 'control' }
'control' variant(:red) { 'red' }
end variant(:blue) { 'blue' }
def red_behavior
'red'
end
def blue_behavior
'blue'
end
end end
``` ```
...@@ -254,13 +212,13 @@ providing the block we were initially providing, by explicitly calling `run`: ...@@ -254,13 +212,13 @@ providing the block we were initially providing, by explicitly calling `run`:
experiment(:pill_color, actor: current_user).run experiment(:pill_color, actor: current_user).run
``` ```
The _behavior_ methods we defined in our experiment class represent the default The _behaviors_ we defined in our experiment class represent the default
implementation. You can still use the block syntax to override these _behavior_ implementation. You can still use the block syntax to override these _behaviors_
methods however, so the following would also be valid: however, so the following would also be valid:
```ruby ```ruby
experiment(:pill_color, actor: current_user) do |e| experiment(:pill_color, actor: current_user) do |e|
e.use { '<strong>control</strong>' } e.control { '<strong>control</strong>' }
end end
``` ```
...@@ -279,11 +237,11 @@ variant, and any account older than 2 weeks old would be assigned the _blue_ var ...@@ -279,11 +237,11 @@ variant, and any account older than 2 weeks old would be assigned the _blue_ var
```ruby ```ruby
class PillColorExperiment < ApplicationExperiment class PillColorExperiment < ApplicationExperiment
# ...registered behaviors
segment(variant: :red) { context.actor.first_name == 'Richard' } segment(variant: :red) { context.actor.first_name == 'Richard' }
segment :old_account?, variant: :blue segment :old_account?, variant: :blue
# ...behaviors
private private
def old_account? def old_account?
...@@ -315,9 +273,9 @@ be nothing - but no events are tracked in these cases as well. ...@@ -315,9 +273,9 @@ be nothing - but no events are tracked in these cases as well.
```ruby ```ruby
class PillColorExperiment < ApplicationExperiment class PillColorExperiment < ApplicationExperiment
exclude :old_account?, ->{ context.actor.first_name == 'Richard' } # ...registered behaviors
# ...behaviors exclude :old_account?, ->{ context.actor.first_name == 'Richard' }
private private
...@@ -327,23 +285,11 @@ class PillColorExperiment < ApplicationExperiment ...@@ -327,23 +285,11 @@ class PillColorExperiment < ApplicationExperiment
end end
``` ```
We can also do exclusion when we run the experiment. For instance,
if we wanted to prevent the inclusion of non-administrators in an experiment, consider
the following experiment. This type of logic enables us to do complex experiments
while preventing us from passing things into our experiments, because
we want to minimize passing things into our experiments:
```ruby
experiment(:pill_color, actor: current_user) do |e|
e.exclude! unless can?(current_user, :admin_project, project)
end
```
You may also need to check exclusion in custom tracking logic by calling `should_track?`: You may also need to check exclusion in custom tracking logic by calling `should_track?`:
```ruby ```ruby
class PillColorExperiment < ApplicationExperiment class PillColorExperiment < ApplicationExperiment
# ...behaviors # ...registered behaviors
def expensive_tracking_logic def expensive_tracking_logic
return unless should_track? return unless should_track?
...@@ -353,16 +299,11 @@ class PillColorExperiment < ApplicationExperiment ...@@ -353,16 +299,11 @@ class PillColorExperiment < ApplicationExperiment
end end
``` ```
Exclusion rules aren't the best way to determine if an experiment is active. Override
the `enabled?` method for a high-level way of determining if an experiment should
run and track. Make the `enabled?` check as efficient as possible because it's the
first early opt-out path an experiment can implement.
### Tracking events ### Tracking events
One of the most important aspects of experiments is gathering data and reporting on One of the most important aspects of experiments is gathering data and reporting on
it. GLEX provides an interface that allows tracking events across an experiment. it. You can use the `track` method to track events across an experimental implementation.
You can implement it consistently if you provide the same context between You can track events consistently to an experiment if you provide the same context between
calls to your experiment. If you do not yet understand context, you should read calls to your experiment. If you do not yet understand context, you should read
about contexts now. about contexts now.
...@@ -373,13 +314,13 @@ the arguments you would normally use when ...@@ -373,13 +314,13 @@ the arguments you would normally use when
of tracking an event in Ruby would be: of tracking an event in Ruby would be:
```ruby ```ruby
experiment(:pill_color, actor: current_user).track(:created) experiment(:pill_color, actor: current_user).track(:clicked)
``` ```
When you run an experiment with any of these examples, an `:assigned` event When you run an experiment with any of the examples so far, an `:assigned` event
is tracked automatically by default. All events that are tracked from an is tracked automatically by default. All events that are tracked from an
experiment have a special experiment have a special
[experiment context](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_experiment/jsonschema/1-0-0) [experiment context](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_experiment/jsonschema/1-0-3)
added to the event. This can be used - typically by the data team - to create a connection added to the event. This can be used - typically by the data team - to create a connection
between the events on a given experiment. between the events on a given experiment.
...@@ -390,28 +331,20 @@ event would be tracked at that time for them. ...@@ -390,28 +331,20 @@ event would be tracked at that time for them.
NOTE: NOTE:
GitLab tries to be sensitive and respectful of our customers regarding tracking, GitLab tries to be sensitive and respectful of our customers regarding tracking,
so GLEX allows us to implement an experiment without ever tracking identifying so our experimentation library allows us to implement an experiment without ever tracking identifying
IDs. It's not always possible, though, based on experiment reporting requirements. IDs. It's not always possible, though, based on experiment reporting requirements.
You may be asked from time to time to track a specific record ID in experiments. You may be asked from time to time to track a specific record ID in experiments.
The approach is largely up to the PM and engineer creating the implementation. The approach is largely up to the PM and engineer creating the implementation.
No recommendations are provided here at this time. No recommendations are provided here at this time.
## Test with RSpec ## Testing with RSpec
This gem provides some RSpec helpers and custom matchers. These are in flux as of GitLab 13.10.
First, require the RSpec support file to mix in some of the basics: In the course of working with experiments, you'll probably want to utilize the RSpec
tooling that's built in. This happens automatically for files in `spec/experiments`, but
for other files and specs you want to include it in, you can specify the `:experiment` type:
```ruby ```ruby
require 'gitlab/experiment/rspec' it "tests experiments nicely", :experiment do
```
You still need to include matchers and other aspects, which happens
automatically for files in `spec/experiments`, but for other files and specs
you want to include it in, you can specify the `:experiment` type:
```ruby
it "tests", :experiment do
end end
``` ```
...@@ -421,28 +354,32 @@ You can stub experiments using `stub_experiments`. Pass it a hash using experime ...@@ -421,28 +354,32 @@ You can stub experiments using `stub_experiments`. Pass it a hash using experime
names as the keys, and the variants you want each to resolve to, as the values: names as the keys, and the variants you want each to resolve to, as the values:
```ruby ```ruby
# Ensures the experiments named `:example` & `:example2` are both # Ensures the experiments named `:example` & `:example2` are both "enabled" and
# "enabled" and that each will resolve to the given variant # that each will resolve to the given variant (`:my_variant` and `:control`
# (`:my_variant` & `:control` respectively). # respectively).
stub_experiments(example: :my_variant, example2: :control) stub_experiments(example: :my_variant, example2: :control)
experiment(:example) do |e| experiment(:example) do |e|
e.enabled? # => true e.enabled? # => true
e.variant.name # => 'my_variant' e.assigned.name # => 'my_variant'
end end
experiment(:example2) do |e| experiment(:example2) do |e|
e.enabled? # => true e.enabled? # => true
e.variant.name # => 'control' e.assigned.name # => 'control'
end end
``` ```
### Exclusion and segmentation matchers ### Exclusion, segmentation, and behavior matchers
You can also test the exclusion and segmentation matchers. You can also test things like the registered behaviors, the exclusions, and
segmentations using the matchers.
```ruby ```ruby
class ExampleExperiment < ApplicationExperiment class ExampleExperiment < ApplicationExperiment
control { }
candidate { '_candidate_' }
exclude { context.actor.first_name == 'Richard' } exclude { context.actor.first_name == 'Richard' }
segment(variant: :candidate) { context.actor.username == 'jejacks0n' } segment(variant: :candidate) { context.actor.username == 'jejacks0n' }
end end
...@@ -450,6 +387,10 @@ end ...@@ -450,6 +387,10 @@ end
excluded = double(username: 'rdiggitty', first_name: 'Richard') excluded = double(username: 'rdiggitty', first_name: 'Richard')
segmented = double(username: 'jejacks0n', first_name: 'Jeremy') segmented = double(username: 'jejacks0n', first_name: 'Jeremy')
# register_behavior matcher
expect(experiment(:example)).to register_behavior(:control)
expect(experiment(:example)).to register_behavior(:candidate).with('_candidate_')
# exclude matcher # exclude matcher
expect(experiment(:example)).to exclude(actor: excluded) expect(experiment(:example)).to exclude(actor: excluded)
expect(experiment(:example)).not_to exclude(actor: segmented) expect(experiment(:example)).not_to exclude(actor: segmented)
...@@ -495,35 +436,36 @@ expect(experiment(:example)).to track(:my_event, value: 1, property: '_property_ ...@@ -495,35 +436,36 @@ expect(experiment(:example)).to track(:my_event, value: 1, property: '_property_
experiment(:example, :variant_name, foo: :bar).track(:my_event, value: 1, property: '_property_') experiment(:example, :variant_name, foo: :bar).track(:my_event, value: 1, property: '_property_')
``` ```
### Recording and assignment tracking
To test assignment tracking and the `record!` method, you can use or adopt the following
shared example: [tracks assignment and records the subject](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/support/shared_examples/lib/gitlab/experimentation_shared_examples.rb).
## Experiments in the client layer ## Experiments in the client layer
This is in flux as of GitLab 13.10, and can't be documented just yet. Any experiment that's been run in the request lifecycle surfaces in `window.gl.experiments`,
and matches [this schema](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_experiment/jsonschema/1-0-3)
so it can be used when resolving experimentation in the client layer.
Any experiment that's been run in the request lifecycle surfaces in and `window.gl.experiments`, Given that we've defined a class for our experiment, and have defined the variants for it, we can publish that experiment in a couple ways.
and matches [this schema](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_experiment/jsonschema/1-0-0)
so you can use it when resolving some concepts around experimentation in the client layer.
### Use experiments in Vue The first way is simply by running the experiment. Assuming the experiment has been run, it will surface in the client layer without having to do anything special.
With the `gitlab-experiment` component, you can define slots that match the name of the The second way doesn't run the experiment and is intended to be used if the experiment only needs to surface in the client layer. To accomplish this we can simply `.publish` the experiment. This won't run any logic, but does surface the experiment details in the client layer so they can be utilized there.
variants pushed to `window.gl.experiments`. For example, if we alter the `pill_color`
experiment to just use the default variants of `control` and `candidate` like so: An example might be to publish an experiment in a `before_action` in a controller. Assuming we've defined the `PillColorExperiment` class, like we have above, we can surface it to the client by publishing it instead of running it:
```ruby ```ruby
def show before_action -> { experiment(:pill_color).publish }, only: [:show]
experiment(:pill_color) do |e|
e.use { } # control
e.try { } # candidate
end.run
end
``` ```
We can make use of the named slots `control` and `candidate` in the Vue component: You can then see this surface in the JavaScript console:
```javascript
window.gl.experiments // => { pill_color: { excluded: false, experiment: "pill_color", key: "ca63ac02", variant: "candidate" } }
```
### Using experiments in Vue
With the `gitlab-experiment` component, you can define slots that match the name of the
variants pushed to `window.gl.experiments`.
We can make use of the named slots in the Vue component, that match the behaviors defined in :
```vue ```vue
<script> <script>
...@@ -534,23 +476,6 @@ export default { ...@@ -534,23 +476,6 @@ export default {
} }
</script> </script>
<template>
<gitlab-experiment name="pill_color">
<template #control>
<button class="bg-default">Click default button</button>
</template>
<template #candidate>
<button class="bg-red">Click red button</button>
</template>
</gitlab-experiment>
</template>
```
When you're coding for an experiment with multiple variants, you can use the variant names.
For example, the Vue component for the previously-defined `pill_color` experiment with `red` and `blue` variants would look like this:
```vue
<template> <template>
<gitlab-experiment name="pill_color"> <gitlab-experiment name="pill_color">
<template #control> <template #control>
...@@ -628,7 +553,7 @@ is viewed as being either `on` or `off`, this isn't accurate for experiments. ...@@ -628,7 +553,7 @@ is viewed as being either `on` or `off`, this isn't accurate for experiments.
Generally, `off` means that when we ask if a feature flag is enabled, it will always Generally, `off` means that when we ask if a feature flag is enabled, it will always
return `false`, and `on` means that it will always return `true`. An interim state, return `false`, and `on` means that it will always return `true`. An interim state,
considered `conditional`, also exists. GLEX takes advantage of this trinary state of considered `conditional`, also exists. We take advantage of this trinary state of
feature flags. To understand this `conditional` aspect: consider that either of these feature flags. To understand this `conditional` aspect: consider that either of these
settings puts a feature flag into this state: settings puts a feature flag into this state:
...@@ -638,7 +563,7 @@ settings puts a feature flag into this state: ...@@ -638,7 +563,7 @@ settings puts a feature flag into this state:
Conditional means that it returns `true` in some situations, but not all situations. Conditional means that it returns `true` in some situations, but not all situations.
When a feature flag is disabled (meaning the state is `off`), the experiment is When a feature flag is disabled (meaning the state is `off`), the experiment is
considered _inactive_. You can visualize this in the [decision tree diagram](#how-it-works) considered _inactive_. You can visualize this in the [decision tree diagram](https://gitlab.com/gitlab-org/ruby/gems/gitlab-experiment#how-it-works)
as reaching the first `Running?` node, and traversing the negative path. as reaching the first `Running?` node, and traversing the negative path.
When a feature flag is rolled out to a `percentage_of_actors` or similar (meaning the When a feature flag is rolled out to a `percentage_of_actors` or similar (meaning the
......
...@@ -117,7 +117,7 @@ RSpec.describe ApplicationExperiment, :experiment do ...@@ -117,7 +117,7 @@ RSpec.describe ApplicationExperiment, :experiment do
describe '#publish_to_database' do describe '#publish_to_database' do
using RSpec::Parameterized::TableSyntax using RSpec::Parameterized::TableSyntax
let(:publish_to_database) { application_experiment.publish_to_database } let(:publish_to_database) { ActiveSupport::Deprecation.silence { application_experiment.publish_to_database } }
shared_examples 'does not record to the database' do shared_examples 'does not record to the database' do
it 'does not create an experiment record' do it 'does not create an experiment record' do
...@@ -358,11 +358,11 @@ RSpec.describe ApplicationExperiment, :experiment do ...@@ -358,11 +358,11 @@ RSpec.describe ApplicationExperiment, :experiment do
stub_feature_flags(namespaced_stub: true) stub_feature_flags(namespaced_stub: true)
end end
it "returns the first variant name" do it "returns an assigned name" do
application_experiment.try(:variant1) {} application_experiment.try(:variant1) {}
application_experiment.try(:variant2) {} application_experiment.try(:variant2) {}
expect(application_experiment.variant.name).to eq('variant1') expect(application_experiment.variant.name).to eq('variant2')
end end
end end
end end
......
...@@ -10,9 +10,23 @@ RSpec.configure do |config| ...@@ -10,9 +10,23 @@ RSpec.configure do |config|
# Disable all caching for experiments in tests. # Disable all caching for experiments in tests.
config.before do config.before do
allow(Gitlab::Experiment::Configuration).to receive(:cache).and_return(nil) allow(Gitlab::Experiment::Configuration).to receive(:cache).and_return(nil)
# Disable all deprecation warnings in the test environment, which can be
# resolved one by one and tracked in:
#
# https://gitlab.com/gitlab-org/gitlab/-/issues/350944
allow(Gitlab::Experiment::Configuration).to receive(:deprecator).and_wrap_original do |method, version|
method.call(version).tap do |deprecator|
deprecator.silenced = true
end
end
end end
config.before(:each, :experiment) do config.before(:each, :experiment) do
stub_snowplow stub_snowplow
end end
end end
# Once you've resolved a given deprecation, you can disallow it here, which
# will raise an exception if it's used anywhere.
ActiveSupport::Deprecation.disallowed_warnings << "`experiment_group?` is deprecated"
# frozen_string_literal: true # frozen_string_literal: true
RSpec.shared_examples 'tracks assignment and records the subject' do |experiment, subject_type| RSpec.shared_examples 'tracks assignment and records the subject' do |experiment, subject_type|
before do
stub_experiments(experiment => true)
end
it 'tracks the assignment', :experiment do it 'tracks the assignment', :experiment do
expect(experiment(experiment)) expect(experiment(experiment))
.to track(:assignment) .to track(:assignment)
...@@ -11,9 +15,7 @@ RSpec.shared_examples 'tracks assignment and records the subject' do |experiment ...@@ -11,9 +15,7 @@ RSpec.shared_examples 'tracks assignment and records the subject' do |experiment
end end
it 'records the subject' do it 'records the subject' do
stub_experiments(experiment => :candidate) expect(Experiment).to receive(:add_subject).with(experiment.to_s, variant: anything, subject: subject)
expect(Experiment).to receive(:add_subject).with(experiment.to_s, variant: :experimental, subject: subject)
action action
end end
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment