the world of model driven development

Posts tagged ‘Development Standards’

The Environment Discipline

Alerce trees live to be some of the oldest trees in their world and are considered a constant and unchanging entity within their environments. Animals and locals in the area use the older, taller trees as a mapping tool to identifying where they are located within the environment.

When modeling often functional needs might arise within the application whereby modellers need to restrict a Microflows to run on Dev or QA environments only. Some examples of cases like this might be when information or functionality needs to be stubbed, test data created or unit test Microflows run on restricted environments. In order to achieve this the application logic needs to know if it is on a Local, Dev or QA environment or not.

What seems to be the best practice so far is to create an “Current Environment” constant. This constant stores the name of the environment that the application is deployed upon. Practically it means modellers need to remember to change this constant when deploying to pre-prod or production (just as they would when changing web service address variables etc).

Essentially the current environment constant means nothing unless the following modeling disciplines are followed:

1. Creating the Constant

A single constant String “currentEnvironment” is created and placed within the downloaded community commons module simply because it’s a good place to put something common that many Microflows over the entire application will use. The String “Dev” is saved as the default value as a safe practice.

2. String Discipline

The following restricted String terms (terms defined and decided upon by the team) are used to define the environments respectively:

  • Dev
  • QA
  • Preprod
  • Prod

3. Adding logic into each Microflow 

Lastly the environment variable can then be used within Microflows as illustrated above. Here the constant can be used to check that the application is in fact deployed on a Dev box before creating test data on it.

Just like Alerce tree environment variables can give Microflows valuable information about which environment they’re on. By following these set of modeling disciplines the team ensures a higher level of quality by ensuring that Microflows are executed upon the exact environments they are supposed to be executed  upon.

Design a site like this with WordPress.com
Get started