When comparing two environments and deploying configuration elements between them, some fields may have inherently different values. For example, a webhook URL in a staging environment may be different than the same webhook's URL in the production environment.
Salto allows users to set environment variables for these fields, in order to specify what should be the unique value for each environment. This helps maintaining the right value for existing elements in each environment, as well as automatically replacing relevant values for elements deployed to a new environment.
Environment Variables structure and behavior
Environment variables consist of:
Scope: which elements and fields should be replaced
The scope is written as a Salto Selector over Salto element IDs. You can use * wildcards to traverse over all instances, or over all members of an array.
For example, if you want to replace values in all Zendesk Webhook Endpoints, the selector should bezendesk.webhook.instance.*.endpoint
Apply variable on all nested fields in this scope:
If disabled, Salto will only replace values in fields directly matching the selector
if enabled, Salto will replace values in all fields matching the selector or nested within it
Environment specific values: what is the expected value in each environment. Values should be in the correct format, as explained here.
Enabled / Disabled: users can easily disable an environment variable
Coming Soon: environment variables will soon support replacing values which appear as substrings of configuration fields. For example, this will allow users to replace dev.acme.org
to prod.acme.org
, even if the domain is found within a wider URL such as https://dev.acme.org/some/webhook/address
When deploying new elements, Salto will replace a value when deploying if:
The current value in the source environment matches the one specified in the environment variable
There is a value set for the target environment (or, if not, in "Any other environment").
When comparing elements between environments, Salto will hide differences that match a variable's source and destination environment values, to help users focus on meaningful differences. In this case, the element will show the value in the destination environment, with a useful popover to show all values:
Salto will also alert when detecting a difference with a value defined only on one side (with no value set for the other side).
Creating an environment variable
There are 2 ways to set a new environment variable:
Directly from an element difference, showed in deployments' comparison view
From the Environment Variables screen, reachable from the user icon -> Org Settings -> Environment Variables
Only organization administrators can create, edit or delete environment variables. The environments will apply to all user deployments.
Creating a new variable from the comparison view
During a deployment's comparison phase, you can set a new environment variable by selecting a "create environment variable" option on a specific difference. Do this on values which are expected to be different, and should not be "aligned".
โ
You can set the variable to apply on the specific instance you're looking at (e.g. a single Jira automation, Zendesk Webhook, Okta application), or on all instances from this type. You can also set a variable which will replace these values across other fields as well, in all elements of this type.
After you select this option, review the suggested environment specific values. Salto auto-populates these values from other environments. You can always choose to customize the rule values, scope, or any other setting from this screen.
After creating an environment variable, configuration differences which have a matching environment variable will not be displayed as a difference. The source and destination values should match the ones specified in the environment variables.
If all differences in an element have matching environment variables, or have been excluded, the entire element row will not be shown in the comparison. Users can always toggle "Show Omitted Elements" to see these.
Creating a new variable from the Environment Variables view
Users can create a new environment variable directly from the Environment Variables view, accessible from user settings -> Org Settings -> Environment Variables:
When you create a new environment variable from this screen, you'll have to manually fill in the scope and environment specific values. For the scope, it is recommended that you copy an element's Salto ID to get a valid scope, and then adapt it to your needs.
Environment specific value types
When setting environment specific values, make sure their type matches the expected value in the elements themselves. Auto-populated values will be formatted correctly.
Type of value | Expected format | Example values |
Boolean |
|
|
Integer | An integer |
|
String | A string surrounded by quotation marks |
|
Reference | A Salto Element ID |
|
If you're not sure about a field's type, go to a configuration element which contains it and view its NACL to determine the expected type.
Environment Variables in deployment previews
When Salto replaces a value to another value during a deployment, the replaced value will be marked in the deployment preview stage. You can see which environment variable caused the replacement.
If the replacement isn't correct, fix your environment variables from the Environment Variables screen, then regenerate the preview.
Examples
Some common usages for environment variables include:
Salesforce email addresses: replace all fields which contain a specific email address, to another email address when deploying to production
Scope: salesforce.*.instance.*
Make sure to enable "Apply variable on all nested fields in this scope"
Jira Automation webhooks: replace all instances of a "Send Web Request" component URL to another URL, in all Jira automations
Scope: jira.Automation.instance.*.components.*.value.url
Coming soon: Salto will soon support replacing values which appear as substrings of configuration fields. Once enabled, we'll support use cases like these:
Zendesk Webhook domains: replace a domain with another domain when deploying to production, on all endpoints
Scope: zendesk.webhook.instance.*.endpoint
Jira Webhook domains: replace a domain with another domain when deploying to production, on all webhooks
Scope: jira.Webhook.instance.*.url