Environments
Dafne is normally deployed several times over — production, testing, development and so on. Each installation knows which environment it is, and can link to the others.
Contents
Environment types
The Environment setting identifies the current installation. It is a drop-down with a fixed set of values:
| Value | Meaning |
|---|---|
| Production | Live processing |
| Testing | Test environment |
| Development | Development environment |
| Acceptance testing | UAT |
| Integration testing | SIT |
| Other1, Other2 | Spare slots for site-specific environments |
The environment is set in Author → Settings; see System settings.
Colour coding
The environment determines the colour of the bar in the main menu. This is the main defence against acting on the wrong installation, and it is worth making sure production is visually unmistakable before anything else is configured.
The environment switcher
The Environment button in the main menu shows the current environment and offers links to the others. Each link opens that installation in a new tab.
An environment appears in the switcher only when its URL base is filled in and begins with http. The current environment is excluded from its own list. If the button is disabled, no other environment has a usable URL base configured.
The URL bases are separate settings, one per environment type:
| Setting | Environment |
|---|---|
| URLBaseProd | Production |
| URLBaseTest | Testing |
| URLBaseDev | Development |
| URLBaseUat | Acceptance testing |
| URLBaseSit | Integration testing |
| URLBaseOther1 | Other1 |
| URLBaseOther2 | Other2 |
Each installation carries its own copy of these settings, so the switcher has to be configured in every environment — not only in one.
The environment placeholder
The current environment is available to tasks and notifications as %env%, resolving to a single-character code:
| Code | Environment |
|---|---|
P |
Production |
T |
Testing |
D |
Development |
U |
Acceptance testing |
S |
Integration testing |
O |
Other1 |
Q |
Other2 |
This is what makes a single task definition safe to deploy everywhere: the statement can branch on the environment, and a notification can say which installation it came from. Including %env% in notification text is strongly advisable where the same definitions run in several places — otherwise an alert from test is indistinguishable from one from production.
See Placeholders.
Deploying between environments
Definitions are moved between installations by export. Two points matter:
- Credentials are not exported. Passwords and authentication keys are omitted, so connections created in the target must have their credentials set by hand.
- Connection definitions can take their values from the environment rather than storing them. Several connection fields have a variable counterpart for this. Where the same definition is deployed to several installations, this is the cleaner approach. See Connection.
Practical notes
- Set the Environment value first on a new installation. Until it is right, the colour coding is wrong, and the colour coding is what stops mistakes.
- Keep the URL bases current. A switcher pointing at a decommissioned host is worse than no switcher.
