Skip to main content

Environment management

Environments isolate the data and configuration of each stage of a workflow's lifecycle. Well organized, they make deployment predictable and prevent a change meant for development from reaching production by accident. To create and configure environments, see Manage environments.

How it fits together​

  • The order of environments in the table determines the deployment flow proposed by default. Configure the order to reflect your lifecycle — DEV → STAGING → PROD — and the deployment interface will automatically propose the next environment.
  • Marking gives environments a role: an environment marked Development is used by default for node tests; an environment marked Production is visually identified as critical.
  • The combination with dictionaries: when a workflow is deployed, Ecosystem automatically uses the dictionary values of the target environment. The same workflow points to the development API in DEV and to the production API in PROD, without modification.
{
  "api_url": "{{dictionaries.api_config.api_url}}"
}
KeyDEVPROD
api_urlhttps://dev-api.example.comhttps://api.example.com

When to use what​

  • A full cycle — create at least DEV, STAGING and PROD: develop and test in DEV, validate in STAGING on test data, deploy to PROD.
  • Multi-tenant — create dedicated environments per client (e.g. PROD-CLIENT-A, PROD-CLIENT-B), each with its own dictionary values.
  • Triggers too — a trigger configuration (e.g. SFTP connection) accepts dictionary variables: the same trigger points to different servers depending on the environment.

What to know before you start​

warning
  • Never use production authentication methods in a development environment.
  • Test fully in DEV and STAGING before production.
  • Each environment must have its own data.

Go further​

See also: Environments