Page tree
Skip to end of metadata
Go to start of metadata

In a production system, you usually have separate hosts at least for development, testing and production. With FRENDS⁴, you can use Environments to manage what Processes and which versions run on the different hosts.

The Environments are just logical constructions for maintaining specific settings. You always assign Agents to different Environments, and the Agents run the Process versions deployed to the Environment. However, you don't need to have an agent configured for an Environment.

By default, a FRENDS⁴ system has only one Environment, named "Default". It is also the only Environment where you can import, create or edit Processes. The "Default" environment always has the latest version of a Process deployed. It can be used as the development Environment, or if that is kept separate, as the Environment where the Processes are imported and then deployed to other Environments.

Usually you have Environments like "Test", "Staging" and "Production" in addition to the "Default" environment. You can, however, also create Environments for e.g. executing Processes on specific hosts or networks.

See Creating and editing Environments and Agents for more on those subjects.

Deploying a Process to another Environment

By default, you can only create and edit Processes in the "Default" environment. You can deploy process versions to other Environments.

You can change the displayed Environment by selecting it from the left-most Environment drop down.

To deploy a version of one process to another Environment, choose Deploy from the Actions menu for the Process. You can also deploy multiple Processes at once by checking the checkboxes at the start of their rows, and choose Deploy from the Batch Actions menu.

After this, you can select the versions of the processes to deploy as well as the Environment where to deploy them to. Clicking Deploy will update the configuration and notify the Agents that they now should use a specific process version (see Agents on the Architecture overview topic for more on the process).

Environment variables

For Environment-specific settings you can define and use Environment variables. You define the available Environment variables in the Environment variables view.

The keys are common across all Environments, but the values can and probably will differ between Environments.

Please note that the environment variable keys must adhere to the following rules

  • No duplicate names allowed. Also note that the keys are case-insensitive.
  • Only letters, numbers and underscores allowed. E.g. no spaces are allowed. Also note that the name cannot start with a number.
  • No C# keywords allowed.

The reason for these restrictions is that the keys are used as is in the generated code, so they need to adhere to the C# specifications for identifiers.

To add a new variable, click on the Add item link at the bottom of the list.

You can define four different types of variables:

  • text: simple text values
  • number: number values
  • yes/no: boolean values
  • list: list of items
  • group: list of named key-value pairs

The list and group can also have sub-keys. They can only be of type text, number or yes/no.

For example, if you have a process that contacts a different FTP server in "Test" and "Production" Environments, you could define an Environment variable like "ftp_server". Then you give the specific server names for "Default", "Test" and "Production" environments. After this, you can reference the environment variable in the process with the reference #env.ftp_server.

The value will be expanded at runtime on the agent running in the specific environment. You can also change the environment variables without re-deploying the processes: any changes to e.g. Test environment variable values will propagate automatically to the agents in the Test environment. They will be used for any new process executions.

  • No labels