2020-10-30 14:08:56 -04:00
---
2020-11-17 10:09:28 -05:00
stage: Growth
group: Activation
2020-11-26 01:09:20 -05:00
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
2020-10-30 14:08:56 -04:00
---
2019-10-16 11:06:17 -04:00
# Experiment Guide
2022-05-05 05:08:00 -04:00
Experiments can be conducted by any GitLab team, most often the teams from the
[Growth Sub-department ](https://about.gitlab.com/handbook/engineering/development/growth/ ).
Experiments are not tied to releases because they primarily target GitLab.com.
Experiments are run as an A/B/n test, and are behind an [experiment feature flag ](../feature_flags/#experiment-type )
to turn the test on or off. Based on the data the experiment generates, the team decides
if the experiment had a positive impact and should be made the new default, or rolled back.
Experiments in GitLab are tightly coupled with the concepts provided by
[Feature flags in development of GitLab ](../feature_flags/index.md ). You're strongly encouraged
to read and understand the [Feature flags in development of GitLab ](../feature_flags/index.md )
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
uses feature flags in development. One concept: experiments can be run with multiple variants,
which are sometimes referred to as A/B/n tests.
We use the [`gitlab-experiment` gem ](https://gitlab.com/gitlab-org/ruby/gems/gitlab-experiment ),
sometimes referred to as GLEX, to run our experiments. The gem exists in a separate repository
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
aware that the documentation there reflects what's in the main branch and may not be the same as
the version being used within GitLab.
## Glossary of terms
To ensure a shared language, you should understand these fundamental terms we use
when communicating about experiments:
- `experiment` : Any deviation of code paths we want to run at some times, but not others.
- `context` : A consistent experience we provide in an experiment.
- `control` : The default, or "original" code path.
- `candidate` : Defines an experiment with only one code path.
- `variant(s)` : Defines an experiment with multiple code paths.
- `behaviors` : Used to reference all possible code paths of an experiment, including the control.
2019-10-16 11:06:17 -04:00
2021-03-10 10:09:11 -05:00
## Implementing an experiment
2021-03-09 13:09:41 -05:00
2021-11-19 22:12:07 -05:00
[`GLEX` ](https://gitlab.com/gitlab-org/ruby/gems/gitlab-experiment ) - or `Gitlab::Experiment` , the `gitlab-experiment` gem - is the preferred option for implementing an experiment in GitLab.
2021-03-09 13:09:41 -05:00
2022-05-05 05:08:00 -04:00
For more information, see [Implementing an A/B/n experiment using GLEX ](implementing_experiments.md ).
2021-03-09 13:09:41 -05:00
2022-01-13 10:14:46 -05:00
This uses [experiment ](../feature_flags/index.md#experiment-type ) feature flags.
2021-05-21 14:11:01 -04:00
### Add new icons and illustrations for experiments
Some experiments may require you to add custom icons or illustrations to our codebase.
This process is lengthy and at this stage, the outcome of the experiment uncertain.
2022-02-11 04:17:45 -05:00
Therefore, you should postpone this effort until the [experiment cleanup process ](https://about.gitlab.com/handbook/engineering/development/growth/experimentation/#experiment-cleanup-issue ).
2021-05-21 14:11:01 -04:00
We recommend the following workflow:
2021-10-17 23:12:16 -04:00
1. Review the Pajamas guidelines for [icons ](https://design.gitlab.com/product-foundations/iconography/ ) and [illustrations ](https://design.gitlab.com/product-foundations/illustration/ ).
2021-05-21 14:11:01 -04:00
1. Add an icon or illustration as an `.svg` file in the `/app/assets/images` (or EE) path in the GitLab repository.
1. Use `image_tag` or `image_path` to render it via the asset pipeline.
1. **If the experiment is a success** , designers add the new icon or illustration to the Pajamas UI kit as part of the cleanup process.
Engineers can then add it to the [SVG library ](https://gitlab-org.gitlab.io/gitlab-svgs/ ) and modify the implementation based on the
[Frontend Development Guidelines ](../fe_guide/icons.md#usage-in-hamlrails-2 ).