Documentation
¶
Overview ¶
Package experiments allow servers to use experimental code paths.
An experiment is essentially like a boolean command line flag: it has a name and it is either set or not. If it is set, the server code may do something differently.
The server accepts a repeated CLI flag `-enable-experiment <name>` to enable named experiments. A typical lifecycle of an experiment is tied to the deployment cycle:
- Implement the code path guarded by an experiment. It is disabled by default. So if someone deploys this code to production, nothing bad will happen.
- Enable the experiment on staging by passing `-enable-experiment <name>` flag. Verify it works.
- When promoting the staging to canary, enable the experiment on canary as well. Verify it works.
- Finally, enable the experiment when promoting canary to stable. Verify it works.
- At this point the experimental code path is running everywhere. Make it default in the code. It makes `-enable-experiment <name>` noop.
- When deploying this version, remove `-enable-experiment <name>` from deployment configs.
The difference from command line flags:
- An experiment is usually short lived. If it needs to stay for long, it should be converted into a proper command line flag.
- The server ignores enabled experiments it doesn't know about. It simplifies adding and removing experiments.
- There's better testing support.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
Types ¶
type ID ¶
type ID struct {
// contains filtered or unexported fields
}
ID identifies an experiment.
The only way to get an ID is to call Register or GetByName.
func GetByName ¶
GetByName returns a registered experiment given its name.
Returns ok == false if such experiment hasn't been registered.
func Register ¶
Register is usually called during init() to declare some experiment.
Panics if such experiment is already registered. The package that registered the experiment can then check if it is enabled in runtime via id.Enabled().
Source Files