Currently, if an organization uses Test Track for multiple environments (e.g. production and stage), it can be a bit difficult to discern at first glance for which environment a user is managing a given split test.
This proposed change gives users the option to set a DEPLOYMENT_ENV_LABEL variable in the .env or .env.local file, which will subsequently be rendered in a bright red banner, like so:
The banner is intentionally a tad obnoxious to make it glaringly obvious to the user which environment they are in.
When no DEPLOYMENT_ENV_LABEL variable is set, the header renders as usual:
I envision organizations using the existing state for production and the banner state for a non-production environment (or perhaps vice-versa).
Summary
Currently, if an organization uses Test Track for multiple environments (e.g. production and stage), it can be a bit difficult to discern at first glance for which environment a user is managing a given split test.
This proposed change gives users the option to set a
DEPLOYMENT_ENV_LABEL
variable in the.env
or.env.local
file, which will subsequently be rendered in a bright red banner, like so:The banner is intentionally a tad obnoxious to make it glaringly obvious to the user which environment they are in.
When no
DEPLOYMENT_ENV_LABEL
variable is set, the header renders as usual:I envision organizations using the existing state for production and the banner state for a non-production environment (or perhaps vice-versa).
/domain @Betterment/test_track_core