Environments

You can create environments containing the initial values of environment-specific variables to use in your journeys. For example, you may have one set of login credentials on your staging environment and another set for your production environment, while your journeys are the same.

Each project can have as many environments as you need, and you can optionally define the environments such that they inherit defaults from one another (see Inheriting environments).

Environment variables can store any value as text (e.g., text, JSON objects, boolean values, numbers, etc.). These values can also be marked as secrets (sensitive information), so they are only shown during creation. This is helpful for storing data such as login credentials.

How to create an environment?

Open the Environments manager page of a project by clicking on the Environments icon on the left menu:

Click on Create environment and fill the information for your environment:

• Name: A unique name that allows you to identify the environment.
• Description (optional): A short description to allow you to identify the purpose of the environment.

After creating the environment, you can add environment variables to it.

How to create an environment variable?

Open the Environment manager, select an environment that you want to create the variable in, and click on Create variable, and fill the name and value for that variable, and click on Create variable. On the example, we show the creation of a variable named username using [email protected] as its value.

The created variable is shown as part of the selected environment. Clicking on the pencil icon will allow modifications to the variable, and clicking on the bin icon will delete the variable.

Sensitive variables

To make the variable be sensitive click on the switch placed after the value input box. Once created, you can still edit it, but you cannot see its previous value.

Inheriting environments

You need to have at least two environments to make one of them inherit from the other one. Once you have both environments created, just click on the environment which will be the child, click on Inherits from, and choose the desired parent environment:

Once you confirm the change, the child environment will inherit all variables from the parent environment. Values defined in the child will take precedence over values in the parent, and values not defined in the child will be automatically updated when changed in the parent environment.

Environment inheritance allows you to define what your tests should use depending on specific environments. As an example we can define a production environment with the URL of the production application, a username, and a password. Then we can define two more environments: staging, which inherits from production and overrides the URL but uses the same credentials and development which inherits from staging and overrides the URL and the password.

To achieve the above use case you can create the following environments:

production
|__staging
   |__development

The result for our example would look like this:

• Environment production declares the next variables: url, username and password.
• Environment staging inherits from production and only declares the variable url to override its inherited value from production.
• Environment development inherits from staging and declares url and password to override their inherited values from staging.

Running a journey with an environment

If you only created a single environment, it's the default environment for your project and it will be used always.

On the other hand, if you have two or more environments, you can choose which one is the default environment for your project:

You can also configure a specific goal to use a different environment. In the goals list, click on Edit settings in the context menu of a goal and then select the environment in "Advanced settings".

If you just want to run a specific goal using a different environment once, you can configure it using the "Execute advanced..." option to run the goal, then choose the environment as part of the execution.

If a goal is executed using an environment that is not the project's default environment, the execution job will be tagged with a tag following this format: environment: <environment-name> (e.g: "environment: development"), so you can filter and locate jobs that used a certain environment.

Using environment variables in your tests

The syntax to be used for our NLP parser is $variableName. Our autocomplete step will suggest to you at the time you start to type the name of one of your variables:

Example:

Write $username in field "Username"
Write $password in field "Password"
Click on "Login"

This syntax is also valid if you want to pass the value of your variable as input for an extension:

Execute myExtension using $myVariable as input

After running your tests, every step that used an environment variable will now have a side effect:

Note that variables marked as sensitive won't show their values: