Assembly-specific environment and specific properties of the boot environment

Question

One of the construction options is to package the environment properties associated with the build time (for example, using maven profiles)

Another option is to set -Denv=production in the production environment, and when loading, load /${env}/config.properties . (spring allows this, for example, but it can be done manually)

I used both. The first means no additional configuration of the environment. The latter allows you to use the same assembly in several environments.

Question: any other significant pluses / minuses, or is it practically the same approach that will be chosen?

Related: Load environment properties for use with PropertyPlaceholderConfigurer?

Answer 1

In my opinion, the presence of different outputs to the environment is a serious drawback, since this means that you need to create N copies of the application, execute the same build commands N times, etc. It is too easy to run into errors when you gave the "dev" version for the QA site, etc.

There is a little third option, between which I am a fan - storing configuration values ​​on the servers themselves, separate from the application, and the application is then either written to know where to find these configuration files, or you have a kind of script that "reconfigures" the application, replacing tokens in configuration files with canonical values ​​from external files.

Thus, you can send the same binary file for all environments, and external configurations can easily be placed under source control (for example, one file for each environment) so that changes can be checked, changes can be automatically propagated, etc. .

This is also a convenient option if you work in a large organization where developers are separated from the group that “manages” the application or is responsible for different environments - because with this method developers can know what to configure, but another group is responsible for what configuration values ​​for each host.

Answer 2

I have 2 assemblies that generate a binary file (a war file without any server configuration) and another project that generates some properties files for each environment environment. The deployment process takes war and related configuration files and does its magic.

I don’t think that sending the configuration from all environments in binary format is good practice ... but mainly because I think there is a chance to run the application with the wrong option, and suddenly the dev application tries to connect to the products.

Another thing is that some properties, such as database connection data or the password of the payment gateway, are stored in another configuration file that belongs to the operations / managed services team. Because we do not want DBA developers or outcasts to work ballistically with a production database.