> For the complete documentation index, see [llms.txt](https://docs.brigge.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brigge.ai/documentation/brigge-for-transformers/environments.md). # Environments ## Introduction If you need the same pipeline structure to run in different contexts (for example, different companies, regions, or build environments), you have a choice: build and maintain separate pipelines for every context, or use the *Environments* feature. With *Environments*, you can save significant time and effort when you need to run essentially the same pipeline for multiple sets of credentials and/or context-specific variables. ### How environments work

There are two key aspects to consider as you start working with *Environments*: * **Pipelines**. A 'base' pipeline defines the *structure* of a workflow - the steps, the logic, the data mappings - without being tied to any specific context. These pipelines should not include anything that binds them to a specific context - you might think of them as 'vanilla' pipelines, where different flavours are added at runtime. * **Environments**. An 'environment' is a container for context-specific items that must be swapped into a pipeline at runtime. When a pipeline is [deployed](/documentation/brigge-for-transformers/pipelines/pipeline-versions-and-deployments.md) to (and so runs in) an environment, the items configured for that environment are swapped into the pipeline at runtime. In this way, you might think of the environment as the flavour added to any vanilla pipelines that are deployed to it. ## Deep dive into the problem being solved To better understand the problem that *Environments* solve, consider the scenarios below.

Scenario 1 (entry-level)

Your organisation has identified the need for 3 pipelines, structured to sync all the data needed to meet business requirements: 1. Invoicing 2. Staff 3. Timesheets However, you need two 'flavours' of each pipeline: one for *Testing* and one for *Production*. The only difference between the two is the authentication credentials for the systems being synced. Without *Environments*, you would need to build and maintain 6 pipelines.

Scenario 2 (more complex)

Your organisation has built 6 pipelines, structured to sync all the data needed to meet a range of business requirements: 1. Staff register 2. Timesheets 3. Invoicing 4. Role updates 5. Reconciliation 6. Monthly report However, your organisation operates 5 agencies under one umbrella group. These agencies use the same external systems, but each has its own authentication credentials. Without *Environments*, you would need to replicate the original set of pipelines 5 times, replacing the system credentials in each case. So now 6 pipelines become 30 pipelines - that's a lot to manage. Now, suppose that each of the 5 agencies runs 2 portfolios: *Legal* and *Medical*, each with different data sources. Suddenly, 60 pipelines would increase to 120 pipelines. And it doesn't stop there. Suppose you need to make a couple of changes to the pipeline structure? That's a couple of changes to 120 pipelines, which is both time-consuming and error-prone.

In both scenarios, we see how multiple versions of the same pipelines are needed for different contexts, and how quickly the number of pipelines can proliferate. With *Environments*, you create a pipeline with the base structure and deploy it to an environment. Each environment is configured with a set of context-specific items (system credentials and/or variables); when the pipeline runs in this environment, those context-specific items are applied. Let's go back to [Scenario 2](#scenario-2-more-complex). We needed 120 pipelines to meet all business requirements. But with environments, it would look something like this:

6 pipelines to build	10 environments to configure
Staff register Timesheets Invoicing Role updates Reconciliation Monthly report	Agency 1 (Legal) Agency 1 (Medical) Agency 2 (Legal) Agency 2 (Medical) Agency 3 (Legal) Agency 3 (Medical) Agency 4 (Legal) Agency 4 (Medical) Agency 5 (Legal) Agency 5 (Medical)

The number of pipelines needed is drastically reduced. Each pipeline is deployed, and the appropriate system credentials are swapped in at runtime. Whilst it may seem there are still many environments to configure, keep in mind that this is a one-off task. Thereafter, it's just a case of maintaining a core set of pipelines. ## Do I have to configure environments? No. A key benefit of using environments is the ability to distil multiple pipelines into one, base structure and apply context-specific elements ([systems](#systems-variables) and [variables](#environment-variables-1)) at runtime. * If you have multiple pipelines that are essentially the same except for system credentials and/or context-specific variables, you should consider using environments. * If your requirements are easily met with relatively few pipelines, or if you have multiple pipelines with different structures and nothing in common, environments will likely be less useful. In this case, you do not need to configure environments. {% hint style="info" %} There is one important caveat to 'not using' environments. To initiate a pipeline run on an [automated trigger](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/trigger-node.md), it must be [deployed](/documentation/brigge-for-transformers/pipelines/pipeline-versions-and-deployments.md). And to deploy a pipeline, an `environment` must be selected. With this in mind, every Brigge implementation has two default environments: `Production` and `Testing`. Whichever of these you choose to use for deployments doesn't matter; the outcome is the same. {% endhint %} ## Configuring environments All work with environments is completed from the [*Environments* page](#user-content-fn-1)[^1]. ![](https://2172380191-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8IqdqwZowcxtFpZfLa6k%2Fuploads%2FkPvStPJRUjfINbdCFU4u%2FEnvironments%20page%20300426.svg?alt=media\&token=adbdd643-a9f2-4752-bf4a-1db6d00272ca) This is where you define the things that vary between environments ([systems](#working-with-systems) and [variables](#environment-variables)), and then the actual [environments](#environments). ### Environment variables In the left panel, select the `variable definitions` option to access `systems` and `variables`. This is where you add and manage all resources that you need to use in environments. At this stage, you're not deciding *which* environments use these items; you're just making them available for selection later. #### Systems When a [system](/documentation/brigge-for-engineers/systems.md) variable is added, all [credentials](/documentation/brigge-for-engineers/credentials.md) for that system will be available for selection when you subsequently [add or edit your environments](#environments). {% hint style="info" %} Start by checking the connector nodes in your pipelines. If the associated system credentials differ between contexts (environments), then you should add that system here. {% endhint %}

Adding systems for use in environments

Cover image

Click the create variable option at the top of the systems panel: 1.png

		Cover image
Click the `create variable` option at the top of the `systems` panel:		1.png
Enter a `label`. This is displayed to users when configuring pipeline connector nodes. Here, you'll notice that any systems added as environment variables are displayed in a separate section of the credentials list in connector nodes. For example:		2.png
Repeat for all systems that you want to make available in your environments.	When you've finished adding/updating systems and variables, save your changes:	3.png

Enter a label. This is displayed to users when configuring pipeline connector nodes. Here, you'll notice that any systems added as environment variables are displayed in a separate section of the credentials list in connector nodes. For example:

2.png

Repeat for all systems that you want to make available in your environments. When you've finished adding/updating systems and variables, save your changes: 3.png

Updating system details for environments

You can change the `label` and/or the associated `system` for a system variable. Note that: * If the system `label` has already been applied to pipeline [connector](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/connector-node.md) nodes, these nodes are updated automatically. * If this system is already [configured in environments](#environments), they are updated automatically.

		Cover image
Click the edit (pencil) icon associated with the system you want to update. For example:		1.png
Update `label` and/or the associated system as needed. For example:		2.png
Save your changes.		3.png

Removing systems from environments

Removing a system variable means: * The credentials for this system are no longer available [when you configure environments](#environments). * If credentials for this system were already [configured in environments](#environments), they are removed. * If the system label has already been applied to pipeline [connector](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/connector-node.md) nodes, the connection is removed, and the connector must be reconfigured. To do this, click the `delete` (trash) icon associated with the system you want to remove and then confirm this action when prompted:

#### Environment variables Environment variables are a powerful way to define context-specific values for use across a range of pipeline steps. For example, you can [set a metadata value](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/set-meta-node.md) to a resolved environment variable; define [routes](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/route-node.md) based on environment variables, output environment variable values to a [set payload](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/set-payload-node.md) step for onward processing, etc.

Adding environment variables

Click the `create variable` option at the top of the `variables` panel:

Then, complete details for the variable (use the table below as a guide).

Field	Summary
Type	Use the dropdown selector to choose a data type for this variable. Standard data types are available, including `text`, `integer`, `date/time`, `boolean`, etc.
Label	The name displayed to users wherever this variable is displayed in the Brigge UI.
Key	A unique identifier used to reference this variable with variable syntax.
Display Type	Determines how this variable is shown to users in the Brigge UI. Choose from: `Form`. The variable is shown on the associated Brigge form in the standard way. `Advanced`. The variable is visible in a collapsed section (named `advanced`) on the associated Brigge form. `None`. The variable is hidden (typically used for variables used behind the scenes, where no user input is required).
Default Value	Enter a static value to be used if the variable cannot be resolved.
Description	Enter descriptive text to provide additional context for this variable.
Secret	If resolved values are sensitive or confidential, toggle this option `on`. Secret variables are encrypted and, wherever surfaced in the Brigge UI, displayed as asterisks.
Required	If the variable value is required for the associated operation to succeed, toggle this option `on`.

If you need to change or remove an existing variable that's been added for environments, use the associated `edit` and `delete` icons:

Updating environment variables

You can change any settings for an environment variable by clicking the associated edit (pencil) icon:

If you update a variable that's already configured in environments, your changes are applied globally. {% hint style="warning" %} If you update a variable that is already in use, be sure to test that your changes have not had any unexpected consequences. {% endhint %}

Removing environment variables

If an environment variable is no longer used in any environments, you can remove it by clicking the associated delete (trash) icon:

### Environments Having defined [systems](#systems) and [variables](#variables), you are ready to configure the environments in which they are used. By default, `Testing` and `Production` environments are configured for Brigge implementations. You can edit these as needed or create new environments.

Creating an environment

		Cover image
Click the plus (+) icon in the environments section of the left panel:		1.png
Enter a name for this environment (as it should be displayed throughout the Brigge UI) and click `save`.		2.png
All systems made available for use in environments are displayed in the first panel. In each case, select the credentials to be used when pipelines run in this environment.		3.png
All variables defined for use in environments are displayed in the second panel. Add values to be applied when pipelines run in this environment.		4.png
Click `save` to confirm your settings. The environment is added to the left panel - for example:		5.png
This environment is now ready for use. When pipelines are deployed to it, the defined system credentials and variables will be swapped in at runtime.		6.png

Editing an environment

To edit environment settings, select the environment name in the left panel and update settings as needed. You can change: * System credentials to be applied. * Variable values. {% hint style="info" %} The environment name can't be changed. If you need a different name, you should [create a new environment](#creating-an-environment). {% endhint %}

Deleting an environment

{% hint style="danger" %} Deleted environments cannot be restored. This is a permanent action. {% endhint %} If an environment is no longer used or was created in error, you can delete it using the delete button at the bottom of the page:

{% hint style="info" %} At least one environment must exist for pipeline deployments. You cannot delete the last remaining environment. {% endhint %}

[^1]: **How do I get there?**\ Select *environments* from the main navigation menu: