Environment settings Pub Share

Our engine is very opinionated about environments and environment settings, which are configured in a specific spec: EnvironmentSettings (it has to have this name).

What is an environment

An environment is a specific deployment, for instance, development vs production or east versus west. Although the projects themselves have an environment designation, we also support multiple environments for each project (the default environment for a project is in fact the one specified when the project was created). This allows you to quickly connect a development environment to a different system.

The environment settings should contain all the settings of all connectors that connect out to other systems, as well as the Guardian settings for polling.

A project is also an environment and changes made in one environment are assumed to be promoted to the other environments in a specific sequence, see below.

Default environments

Although you can define more environments, there are 4 default environments with specific functionality:

• local - this is active in local development and is only active when the server runs on the localhost. Likewise, the Guardian only runs the local tests when on the localhost
• sandbox (optional) - development/on cloud. All local changes are normally promoted to this one, so you can test changes on the cloud
• dev - development. All local changes are normally promoted to this one, so the team can share, merge and test all changes
• qa - this is the QA environment, normally multiple teams coming together
• prod - the production environment

Each project will default to the kind that it was created with (i.e. devapp1org will default to "dev").

How to specify the environments

Remember that each project will default to the kind that it was created with (i.e. devapp1org will default to "dev"), so most projects will only have one "environment", let's say "dev".

The current environment is available as: diesel.env. This can be changed from the selection drop-down or by the automated Guardian, when running a test.

Configuring this environment's settings is done as a regular rule, using the diesel.setEnv message. This message is raised when tests start and you can intercept it and set your specific properties, depending on the current environment, here's a classic example, to set the properties for dev and qa:

This is the current environment setting: **diesel.env**

$when diesel.setEnv(env == "dev")
=> ctx.set (
    CUSTMGR_URL = "https://devxxx.amazonhosting.io/custMgrService",
    APP_ID = "some big secret"
    )

$when diesel.setEnv(env == "qa")
=> ctx.set (
    CUSTMGR_URL = "https://qaxxx.amazonhosting.io/custMgrService",
    APP_ID = "some bigger secret"
    )

Note that these messages are usually tagged with <trace> so they don't appear by default in the trace view. You will need to check the "trace" box to see these.

If you use environment settings, they should be all put in a specification called EnvironmentSettings and tagged as a spec (Spec:EnvironmentSettings). This special spec is included in all the tests, before any other stories.

Using multiple environments

If you want to use multiple environments inside a single project, you'll need to configure:

• the list of available environments
• the settings for each environment.

The list of available environments should be specified in the reactor settings:

diesel.envList=local,dev,qa,prod

A better idea is to set it directly inside the Environment Settings:

$when diesel.realm.configure
=> diesel.realm.set(diesel.envList = "local,dev,qa,prod")

When you configure a list of environments, you will automatically get a dropdown at the top-right, to change the current environment - the current environment is remembered in your personal settings for this project, so you don't have to select it every time:

Configuring each of these is done as a regular rule, using the diesel.setEnv message, here's a classic example:

$when <trace> diesel.before
=> ctx.echo(msg=diesel.env)

$when diesel.setEnv(env == "sandbox1")
=> ctx.set (
    CUSTMGR_URL = "https://sandbox1xxx.amazonhosting.io/custMgrService",
    APP_ID = "some big secret"
    )

$when diesel.setEnv(env == "dev")
=> ctx.set (
    CUSTMGR_URL = "https://devxxx.amazonhosting.io/custMgrService",
    APP_ID = "some big secret"
    )

The current environment

The current environment may differ, depending on the context:

• when using the website, in the fiddles or such, there is a single setting for the current environment.
• the guardian is active for multiple environments - every time it runs, it will first set the environment for which it was triggered
• some messages may overwrite and set their own environment, especially for instance when calling them from portals etc

Overwriting the environment settings

Let's say you interact with three sub-systems: A,B and C. You have env settings for each of these, for dev,prod,qa etc. You have the ability to shoot yourself in the foot, by overwriting the environment settings for a particular sub-system.

This may sometimes be useful if you want to point your localhost environment to

Realm lifecycle

diesel.realm.load

This message is sent only onece, when a node is started. It's purpose is to setup any connections or schedules etc.

diesel.realm.configure

The purpose of this message is to configure the current realm. It is sent when the realm is loaded and also every time the reactor settings change. Do not create any long-lived objects here or have any resource leak!

$when diesel.realm.configure
=> diesel.realm.set(diesel.envList = "local,dev,qa,prod")

NOTE that the Environment Settings rules are also included in all derived projects (any project that has this project as a mixin). Therefore, if there are initializations that should only happen once, like database installs etc, be sure to double check the realm parameter - this is a typical application:

$when diesel.realm.configure(realm,env)
=> diesel.realm.set(diesel.envList = "local,dev,qa,prod")
=> my.init.db(realm)

$when my.init.db(realm is "myproject")
=> ...

OR... just make the configure applicable for this specific realm:

$when diesel.realm.configure (realm is "myproject")
...

The database will only be initialized once even if this is the base project for several portals.

You need to log in to post a comment!