gitlab-experiment 0.4.1 → 0.4.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 740552e72dc8655bde106bbca76a2b5be2776196ad957c780cf06d2bc3324a11
-  data.tar.gz: 19f8fbc4588b8efcff729464b5f3480a9d41a0429f8ea8153d097a0c9c948aae
+  metadata.gz: 865d51c081670824fc7ffb48d4bc764fd5370606d3aa63b2196421b5570506e7
+  data.tar.gz: a007f872a3d56ee81c9925117f603e4930d1b7d689078edb074a2ba5567833f2
 SHA512:
-  metadata.gz: b4f4b3f0a7c56087a0bccaf916d568a82ad02cd7784ba94e86254f3c11fabc106cf5da171d889d95818fb4229b34ab9712ddddf597c2dc6075d724c3c08af80b
-  data.tar.gz: aa6c559ca3e62e810ffa8efd7b1846da0beefd6ad91c10e425d7ed1477eb3073cb792b909d39199cb5847ce1b25d9bf19189793190f6e5a519c43468a341fe02
+  metadata.gz: 03d401a71b952b74519a21fa851a87ee9e104ccd19011af37ac41c36bec5fd63db3e68c62c05beb34ab296d354e00e15f013dd34a547c3b4c5c94474b89096cc
+  data.tar.gz: 2bb0260e40d4689446c1317273d85140fae9f56394821fda96c7bbc5d1acbe441f3e4024bf00ec05812f64f5588897137fc8061e790d871c5719742f6cedf516

data/README.md

@@ -1,4 +1,5 @@
-# GitLab Experiment
+GitLab Experiment
+=================
 
 <img alt="experiment" src="/uploads/60990b2dbf4c0406bbf8b7f998de2dea/experiment.png" align="right" width="40%">
 
@@ -16,6 +17,8 @@ When we discuss the behavior of this gem, we'll use terms like experiment, conte
 
 Candidate and variant are the same concept, but simplify how we speak about experimental paths.<br clear="all">
 
+[[_TOC_]]
+
 ## Installation
 
 Add the gem to your Gemfile and then `bundle install`.
@@ -24,7 +27,7 @@ Add the gem to your Gemfile and then `bundle install`.
 gem 'gitlab-experiment'
 ```
 
-If you're using Rails, you can install the initializer. It provides basic configuration and documentation.
+If you're using Rails, you can install the initializer which provides basic configuration, documentation, and the base experiment class that all your experiments can inherit from.
 
 ```shell
 $ rails generate gitlab:experiment:install
@@ -79,72 +82,84 @@ To this end, we track events that are important by calling the same experiment e
 experiment(:notification_toggle, actor: user).track(:clicked_button)
 ```
 
-<details>
-  <summary>You can also use the more low level class or instance interfaces...</summary>
+### Custom experiments
 
-### Class level interface using `.run`
+You can craft more advanced behaviors by defining custom experiments at a higher level. To do this you can define a class that inherits from `ApplicationExperiment` (or `Gitlab::Experiment`).
 
-```ruby
-exp = Gitlab::Experiment.run(:notification_toggle, actor: user) do |e|
-  # Context may be passed in the block, but must be finalized before calling
-  # run or track.
-  e.context(project: project) # add the project to the context
+Let's say you want to do more advanced segmentation, or provide default behavior for the variants on the experiment we've already outlined above -- that way if the variants aren't defined in the block at the time the experiment is run, these methods will be used. 
 
-  # Define the control and candidate variant.
-  e.use { render_toggle } # control
-  e.try { render_button } # candidate
-end
+You can generate a custom experiment by running:
 
-# Track an event on the experiment we've defined.
-exp.track(:clicked_button)
-```
+```shell
+$ rails generate gitlab:experiment NotificationToggle control candidate
+``` 
+
+This will generate a file in `app/experiments/notification_toggle_experiment.rb`, as well as a test file for you to further expand on.
 
-### Instance level interface
+Here are some examples of what you can introduce once you have a custom experiment defined.
 
 ```ruby
-exp = Gitlab::Experiment.new(:notification_toggle, actor: user)
-# Additional context may be provided to the instance (exp) but must be
-# finalized before calling run or track.
-exp.context(project: project) # add the project id to the context
+class NotificationToggleExperiment < ApplicationExperiment
+  # Segment any account less than 2 weeks old into the candidate, without
+  # asking the variant resolver to decide which variant to provide.
+  segment :account_age, variant: :candidate
+
+  # Define the default control behavior, which can be overridden at
+  # experiment time.
+  def control_behavior
+    render_toggle
+  end
+
+  # Define the default candidate behavior, which can be overridden
+  # at experiment time.
+  def candidate_behavior
+    render_button
+  end
+
+  private
 
-# Define the control and candidate variant.
-exp.use { render_toggle } # control
-exp.try { render_button } # candidate
+  def account_age
+    context.actor && context.actor.created_at < 2.weeks.ago
+  end
+end
 
-# Run the experiment, returning the result.
+# The class will be looked up based on the experiment name provided. 
+exp = experiment(:notification_toggle, actor: user)
+exp # => instance of NotificationToggleExperiment
+
+# Run the experiment -- returning the result.
 exp.run
 
 # Track an event on the experiment we've defined.
 exp.track(:clicked_button)
 ```
 
-</details>
+You can now also do things very similar to the simple examples and override the default variant behaviors defined in the custom experiment -- keeping in mind that this should be carefully considered within the scope of your experiment.
+
+```ruby
+experiment(:notification_toggle, actor: user) do |e|
+  e.use { render_special_toggle } # override default control behavior
+end
+```
 
 <details>
-  <summary>You can define and use custom classes...</summary>
+  <summary>You can also use the lower level class interface...</summary>
 
-### Custom class
+### Using the `.run` approach
 
-```ruby
-class NotificationExperiment < Gitlab::Experiment
-  def initialize(variant_name = nil, **context, &block)
-    super(:notification_toggle, variant_name, **context, &block)
+This is useful if you haven't included the DSL and so don't have access to the `experiment` method, but still want to execute an experiment. This is ultimately what the `experiment` method calls through to, and the method signatures are the same.
 
-    # Define the control and candidate variant.
-    use { render_toggle } # control
-    try { render_button } # candidate
-  end
-end
+```ruby
+exp = Gitlab::Experiment.run(:notification_toggle, actor: user) do |e|
+  # Context may be passed in the block, but must be finalized before calling
+  # run or track.
+  e.context(project: project) # add the project to the context
 
-exp = NotificationExperiment.new(actor: user) do |e|
-  # Context may be provided within the block or to the instance (exp) but must
-  # be finalized before calling run or track.
-  e.context(project: project) # add the project id to the context
+  # Define the control and candidate variant.
+  e.use { render_toggle } # control
+  e.try { render_button } # candidate
 end
 
-# Run the experiment -- returning the result.
-exp.run
-
 # Track an event on the experiment we've defined.
 exp.track(:clicked_button)
 ```
@@ -152,11 +167,11 @@ exp.track(:clicked_button)
 </details>
 
 <details>
-  <summary>You can also specify the variant to use...</summary>
+  <summary>You can also specify the variant to use for segmentation...</summary>
 
 ### Specifying variant
 
-You can hardcode the variant if you want. It's important to know what this might do to your data during rollout, so use this with consideration.
+Generally, defining segmentation rules is a better way to approach routing into specific variants, but it's possible to explicitly specify the variant when running an experiment. It's important to know what this might do to your data during rollout, so use this with careful consideration.
 
 ```ruby
 experiment(:notification_toggle, :no_interface, actor: user) do |e|
@@ -188,6 +203,25 @@ end
 
 </details>
 
+### Segmentation rules
+
+This library comes with the capability to segment contexts into a specific variant, before asking the variant resolver which variant to provide.
+
+Segmentation can be achieved by using a custom experiment class and specifying the segmentation rules at a class level.
+
+```ruby
+class NotificationToggleExperiment < ApplicationExperiment
+  segment(variant: :variant_one) { context.actor.username == 'jejacks0n' }
+  segment(variant: :variant_two) { context.actor.created_at < 2.weeks.ago }
+end
+```
+
+In the previous examples, any user with the username `'jejacks0n'` would always receive the experience defined in "variant_one". As well, any account less than 2 weeks old would get the alternate experience defined in "variant_two".
+
+When an experiment is run, the segmentation rules are executed in the order they're defined. The first segmentation rule to produce a truthy result is the one which gets used to assign the variant. The remaining segmentation rules are skipped.
+
+This means that any user with the name `'jejacks0n'`, regardless of account age, will always be provided the experience as defined in "variant_one". 
+
 ### Return value
 
 By default the return value is a `Gitlab::Experiment` instance. In simple cases you may want only the results of the experiment though. You can call `run` within the block to get the return value of the assigned variant.
@@ -351,4 +385,32 @@ If you only include a user, that user would get the same experience across every
 
 Each of these approaches could be desirable given the objectives of your experiment.
 
-### Make code not war
+## Development
+
+After checking out the repo, run `bundle install` to install dependencies.
+Then, run `bundle exec rspec` to run the tests. You can also run `bundle exec pry` for an
+interactive prompt that will allow you to experiment.
+
+## Contributing
+
+Bug reports and merge requests are welcome on GitLab at
+https://gitlab.com/gitlab-org/gitlab-experiment. This project is intended to be a
+safe, welcoming space for collaboration, and contributors are expected to adhere
+to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
+
+## Release Process
+
+Please refer to the [Release Process](docs/release_process.md).
+
+## License
+
+The gem is available as open source under the terms of the
+[MIT License](http://opensource.org/licenses/MIT).
+
+## Code of Conduct
+
+Everyone interacting in the `Gitlab::Experiment` project’s codebases, issue trackers,
+chat rooms and mailing lists is expected to follow the
+[code of conduct](CODE_OF_CONDUCT.md).
+
+***Make code not war***

data/lib/generators/gitlab/experiment/install/templates/initializer.rb.tt

@@ -7,20 +7,28 @@ Gitlab::Experiment.configure do |config|
   # The logger is used to log various details of the experiments.
   config.logger = Logger.new($stdout)
 
-  # The base class that should be instantiated for basic experiments.
+  # The base class that should be instantiated for basic experiments. It should
+  # be a string, so we can constantize it later.
   config.base_class = 'ApplicationExperiment'
 
-  # The caching layer is expected to respond to fetch, like Rails.cache.
+  # The caching layer is expected to respond to fetch, like Rails.cache for
+  # instance -- or anything that adheres to ActiveSupport::Cache::Store.
   config.cache = nil
 
+  # The domain to use on cookies.
+  #
+  # When not set, it uses the current host. If you want to provide specific
+  # hosts, you use `:all`, or provide an array like
+  # `['www.gitlab.com', '.gitlab.com']`.
+  config.cookie_domain = :all
+
   # Logic this project uses to resolve a variant for a given experiment.
   #
-  # This can return an instance of any object that responds to `name`, or can
-  # return a variant name as a string, in which case the build in variant
-  # class will be used.
+  # Should return a symbol or string that represents the variant that should
+  # be assigned.
   #
-  # This block will be executed within the scope of the experiment instance,
-  # so can easily access experiment methods, like getting the name or context.
+  # This block is executed within the scope of the experiment and so can access
+  # experiment methods, like `name`, `context`, and `signature`.
   config.variant_resolver = lambda do |requested_variant|
     # Run the control, unless a variant was requested in code:
     requested_variant || 'control'
@@ -28,23 +36,12 @@ Gitlab::Experiment.configure do |config|
     # Run the candidate, unless a variant was requested, with a fallback:
     #
     # requested_variant || variant_names.first || 'control'
-
-    # Using Unleash to determine the variant:
-    #
-    # fallback = Unleash::Variant.new(name: requested_variant || 'control', enabled: true)
-    # Unleash.get_variant(name, context.value, fallback)
-
-    # Using Flipper to determine the variant:
-    #
-    # TODO: provide example.
-    # Variant.new(name: requested_variant || 'control')
   end
 
   # Tracking behavior can be implemented to link an event to an experiment.
   #
-  # Similar to the variant_resolver, this is called within the scope of the
-  # experiment instance and so can access any methods on the experiment,
-  # such as name and signature.
+  # This block is executed within the scope of the experiment and so can access
+  # experiment methods, like `name`, `context`, and `signature`.
   config.tracking_behavior = lambda do |event, args|
     # An example of using a generic logger to track events:
     config.logger.info "Gitlab::Experiment[#{name}] #{event}: #{args.merge(signature: signature)}"
@@ -61,8 +58,11 @@ Gitlab::Experiment.configure do |config|
   # Called at the end of every experiment run, with the result.
   #
   # You may want to track that you've assigned a variant to a given context,
-  # or push the experiment into the client or publish results elsewhere, like
-  # into redis. Also called within the scope of the experiment instance.
+  # or push the experiment into the client or publish results elsewhere like
+  # into redis.
+  #
+  # This block is executed within the scope of the experiment and so can access
+  # experiment methods, like `name`, `context`, and `signature`.
   config.publishing_behavior = lambda do |result|
     # Track the event using our own configured tracking logic.
     track(:assignment)
@@ -83,14 +83,11 @@ Gitlab::Experiment.configure do |config|
   # Given a specific context hash map, we need to generate a consistent hash
   # key. The logic in here will be used for generating cache keys, and may also
   # be used when determining which variant may be presented.
+  #
+  # This block is executed within the scope of the experiment and so can access
+  # experiment methods, like `name`, `context`, and `signature`.
   config.context_hash_strategy = lambda do |context|
     values = context.values.map { |v| (v.respond_to?(:to_global_id) ? v.to_global_id : v).to_s }
     Digest::MD5.hexdigest((context.keys + values).join('|'))
   end
-
-  # The domain for which this cookie applies so you can restrict to the domain level.
-  #
-  # When not set, it uses the current host. If you want to provide specific hosts, you can
-  # provide them either via an array like `['www.gitlab.com', .gitlab.com']`, or set it to `:all`.
-  config.cookie_domain = :all
 end

data/lib/gitlab/experiment.rb

@@ -76,10 +76,11 @@ module Gitlab
     end
 
     def variant(value = nil)
-      return @variant_name = value unless value.nil?
+      @variant_name = value unless value.blank?
+      @variant_name ||= :control if excluded?
 
-      result = instance_exec(@variant_name, &Configuration.variant_resolver)
-      result.respond_to?(:name) ? result : Variant.new(name: (result.presence || :control).to_s)
+      resolved = cache { resolve_variant_name }
+      Variant.new(name: (resolved.presence || :control).to_s)
     end
 
     def exclude(&block)
@@ -88,19 +89,13 @@ module Gitlab
 
     def run(variant_name = nil)
       @result ||= begin
-        @variant_name = variant_name unless variant_name.nil?
-        @variant_name ||= :control if excluded?
-
-        chain = variant_assigned? ? :unsegmented_run : :segmented_run
-        run_callbacks(chain) do
-          variant_name = cache { variant.name }
-
-          method_name = "#{variant_name}_behavior"
-          if respond_to?(method_name)
-            behaviors[variant_name] ||= -> { send(method_name) } # rubocop:disable GitlabSecurity/PublicSend
+        variant_name = variant(variant_name).name
+        run_callbacks(variant_assigned? ? :unsegmented_run : :segmented_run) do
+          if respond_to?((behavior_name = "#{variant_name}_behavior"))
+            behaviors[variant_name] ||= -> { send(behavior_name) } # rubocop:disable GitlabSecurity/PublicSend
           end
 
-          super(variant_name)
+          super(@variant_name = variant_name)
         end
       end
     end
@@ -140,7 +135,7 @@ module Gitlab
     end
 
     def id
-      "#{name}:#{signature[:key]}"
+      "#{name}:#{key_for(context.value)}"
     end
     alias_method :session_id, :id
 
@@ -154,6 +149,15 @@ module Gitlab
 
     protected
 
+    def resolve_variant_name
+      return :unresolved if @resolving
+
+      @resolving = true
+      result = instance_exec(@variant_name, &Configuration.variant_resolver)
+      @resolving = false
+      result
+    end
+
     def generate_result(variant_name)
       observation = Scientist::Observation.new(variant_name, self, &behaviors[variant_name])
       Scientist::Result.new(self, [observation], observation)

data/lib/gitlab/experiment/caching.rb

@@ -14,8 +14,8 @@ module Gitlab
 
       def cache_strategy
         [
-          "#{name}:#{signature[:key]}",
-          signature[:migration_keys]&.map { |key| "#{name}:#{key}" }
+          "#{name}:#{context.signature[:key]}",
+          context.signature[:migration_keys]&.map { |key| "#{name}:#{key}" }
         ]
       end
 

data/lib/gitlab/experiment/configuration.rb

@@ -18,12 +18,15 @@ module Gitlab
       # The base class that should be instantiated for basic experiments.
       @base_class = 'Gitlab::Experiment'
 
-      # Cache layer. Expected to respond to fetch, like Rails.cache.
+      # The caching layer is expected to respond to fetch, like Rails.cache.
       @cache = nil
 
+      # The domain to use on cookies.
+      @cookie_domain = :all
+
       # Logic this project uses to resolve a variant for a given experiment.
       @variant_resolver = lambda do |requested_variant|
-        requested_variant || 'control'
+        requested_variant || :control
       end
 
       # Tracking behavior can be implemented to link an event to an experiment.
@@ -31,8 +34,7 @@ module Gitlab
         Configuration.logger.info "Gitlab::Experiment[#{name}] #{event}: #{args.merge(signature: signature)}"
       end
 
-      # Called at the end of every experiment run, with the results. You may
-      # want to push the experiment into the client or push results elsewhere.
+      # Called at the end of every experiment run, with the result.
       @publishing_behavior = lambda do |_result|
         track(:assignment)
       end
@@ -43,22 +45,17 @@ module Gitlab
         Digest::MD5.hexdigest(([name] + hash_map.keys + values).join('|'))
       end
 
-      # The domain for which this cookie applies so you can restrict to the domain level.
-      # When not set, it uses the current host. If you want to provide specific hosts, you can
-      # provide them either via an array like `['www.gitlab.com', .gitlab.com']`, or set it to `:all`.
-      @cookie_domain = :all
-
       class << self
         attr_accessor(
           :name_prefix,
           :logger,
           :base_class,
           :cache,
+          :cookie_domain,
           :variant_resolver,
           :tracking_behavior,
           :publishing_behavior,
-          :context_hash_strategy,
-          :cookie_domain
+          :context_hash_strategy
         )
       end
     end

data/lib/gitlab/experiment/version.rb

@@ -2,6 +2,6 @@
 
 module Gitlab
   class Experiment
-    VERSION = '0.4.1'
+    VERSION = '0.4.2'
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: gitlab-experiment
 version: !ruby/object:Gem::Version
-  version: 0.4.1
+  version: 0.4.2
 platform: ruby
 authors:
 - GitLab
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2020-11-17 00:00:00.000000000 Z
+date: 2020-11-19 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activesupport