Best practice for installation and deployment
The following pages include Brainwave's Best Practices to follow when deploying and configuring a project.
It is possible to override the parameters configured in the technical configuration using
.properties files. Please be aware that there are pros & cons to using the
Single .configuration file
It allows you to have a single
.configuration file for all your environments (often called
Using the properties files you override / overload only environment specific variables, for instance the database or SMTP server connection information.
The rest of the variables values are only set once in the common configuration.
There is no need to deliver a new project version to fix a variable value, as it can be updated in the
.properties files directly.
In some contexts, maintenance of some environments (i.e. Prod) are done by other teams than the iGRC project team.
It's often easier for them to update the
.properties files without having to update the project itself and mess with the technical configuration file.
Projects are often using a versioning system (i.e. Git) that track changes to the configuration files (excluding development configurations).
Properties files updates will not be tracked in the versioning system (unless those files are also in Git, but that is rarely the case).
There can be discrepancies between the variables existing in the configuration files & the ones in the properties files, because the project evolves.
It can be hard to track / update.
Also see the warnings section at the end
Properties files can be used to override the technical configuration values.
It means that if a configuration variable value exists in both the
.properties files and in the technical configuration file, the value from the
.properties files will be used in prior by the project.
If there is no value in the
.properties files, then the variable value from the technical configuration file will be used.
.properties files can be generated from the technical configuration file's
Variables tab by clicking on
Export to properties files 💾:
This will generate the following files (listed with their corresponding tab in the configuration file):
config.properties: web portal configuration (
datasource.properties: ledger database connection information (
mail.properties: email & smtp server configuration (
project.properties: configuration variables (
workflow.properties: workflow database connection (
.properties files is optional, but a
license.lic file is often required in the properties folder, see below
.properties files with the web portal, update the
License and properties files directory location value in the
Export tab of the technical configuration to
Point to the following directory:
.properties files in the batch, use the
config directory path parameter of the batch.
As shown in the
igrc_batch.cmd help, it's the second parameter,
<config directory path>:
echo "Expecting at least 3 parameters: <project name> <config directory path> <config name> [SIMULATE or FORCE]. Aborting..."
echo "usage: igrc_batch <project name> <config folder> <config name> [SIMULATE]"
echo "<project name> is the project name"
echo "<config directory path> can contain several of these files:"
So for example
igrc_batch.cmd Sandbox C:\Users\scabon\Documents\Properties\Sandbox dev where
C:\Users\scabon\Documents\Properties\Sandbox is the path to the folder containing the
As explained previously, if no
.properties files are present in the folder, variables values from the project will be considered. The only mandatory file in this folder is the license.
The studio always uses the values from the technical configuration file for the collect / timeslots, it cannot overload values using the
But if your webapp points to the project, you can add
.properties files to your
/webportal folder to overload their values.
license.lic file is often put in the same folder as the
As using the
.properties files is optional, it is possible to have only the
license.lic file in the path to the properties folder for either the batch or the portal, as they both require a license to function properly.
It's easy to forget that new variables were added to the project (for example because a new facet was installed, presence of a new
.configvariables file in your project), and to add those to the
.configuration files, meaning that only some of the configuration variables are overloaded by properties.
It means that each time:
- A new
.configvariablesfile appears in your project, do not miss to add new variables in your
.configurationfile (by simply opening and save it)
- A new variable is added to the
.configurationfile of your project, you should set its value and export
But, in that case, take care about not to overwrite some existing values in your
.properties files not identical to your project configuration.
Generating the properties files from the Studio creates files with a subset of all possible variables.
I.e. not all variables that can be overloaded are listed (for the
webportal for instance).
For instance, from the
Mail server tab, it is possible to set
recipientsinattachment properties but those are not exported in
Here is the result of the export of the