Environment Variables or YAML Configuration Files

Question

Background:
Step 1 → We have a box that runs unit and functional tests of the application, launching it in test mode with a specific configuration.
Step 2 → After the success in step 1, we run the integration tests of the application, running it in test mode with a different set of configurations in another window.
Step 3 → After the success in step 2, we run the application performance tests by running it in production mode in the performance test window.
Step 4 → After the success in step 3, the assembly is considered stable, and the UAT field is updated with this code base, and the application is launched in production mode, for viewing and customer feedback. Step 5 → With GO from the client, the production box is updated with a code base.

Now, from the previous steps, we see that in steps 1 and 2, when the application is in test mode, it has a different configuration. As with steps 3.4 and 5.

In such situations, what is recommended? We had YAML configuration files, but I personally felt that saving multiple configuration files did not make sense. So, I have changed from the practice of "configuration file for each environment"
for the image "Configuration file for rails mode, externalizing variables in linux environment" .

Am I on the right track? Doesn't my action simplify?

What are the pros and cons of these two approaches?

Answer 1

In my experience, environment variables are configuration parameters of the latter. They absolutely have their place, but applications usually should first check out some more reliable and explicitly deliberate configuration parameters. I highly recommend downloading the configuration from the YAML file and using the environment variable as a backup. Always assume that your environment variable will apply to the whole system-wide, and suppose that at some point it will not be accidentally canceled or an incorrect value will be set. those. your application should not execute seppuku because some configuration directory got the value / and it does not have rights to it (or, even worse, you deleted your disk because the application was running as root ). Or, most likely, something like your RAILS_ENV was set to test when it was supposed to be production , and no one understood, and now users are writing data in the wrong place or in /dev/null due to all 500.

Personally, I like to drop logger.warn messages anytime I return to the environment variable for the configuration value.

With your exact problem, to be honest, I would probably pass in the configuration value for which the environment runs on the command line.

Answer 2

In my company, we actually have both.

We have a Rails application that can point to one of many different installations of other software and use the APIs from that installation. To indicate the installation, you need to set about 5 variables.

We used each of these variables as separate environment variables, but having established that they all became old very quickly, we inevitably forgot it.

So now we have one environment variable that we call ENV_TOKEN, and we have yaml files containing entries that match the actual ENV_TOKEN variables, and the code in config / initializers, which sets the value to ENV [key] =.

So, let's say I have the “FOO” and “BAR” variables, which I want to set to “one” and “two”, respectively. I can create a yaml file that contains:

 carolclarinet: FOO: one BAR: two 

and then I would set my ENV_TOKEN environment variable to carolclarinet, and FOO and BAR to one and two.

I have no idea how this is the best way to do this, but it works for us.

ETA: Please note that this is only for development and testing, the installer of our software takes care of installing all this so that our clients never change any environment variables.

Answer 3

After a thorough thorough Google search , discussions with some people from Rails, and brainstorming, I made changes to the code so that I have a "rails-mode configuration file that outputs the application configurations to a YML file, which in my case remains outside the Rails environment"

Follow the clear snippets of code to understand how I can achieve this in a simple way. A quick explanation is that the code snippet in the environment.rb file reads the YAML file from the system to copy all the key-value pairs to the Rails ENV hash. This ENV hash is available everywhere, while / on / after downloading the application.

 File: config/environment.rb # Mechanism to load all application related configurations $CONFIG_FILE = "/var/myapp/config/jsconfig.yml" require 'yaml' APP_CONFIG = YAML.load_file($CONFIG_FILE) APP_CONFIG.each do |key, value| ENV[key] = value end #3rd Party Server (that my application is using) Configurations here... 3RD_PARTY_SERVER_URL = ENV['3rd_party_webservice_endpoint_url'] 3RD_PARTY_SERVER_CREDENTIALS = {:username => ENV['3rd_party_server_username'], :password=> ENV['3rd_party_server_password']} File: /var/myapp/config/jsconfig.yml 3rd_party_webservice_endpoint_url: url 3rd_party_server_username: username 3rd_party_server_password: password myapp_db_url: jdbc:oracle:thin:@localhost:1521:XE myapp_db_username: kartz myapp_db_password: rails_savvy File: /var/myapp/config/database.yml development: adapter: oracle_enhanced url: <%= ENV['myapp_db_url'] %> username: <%= ENV['myapp_db_username'] %> password: <%= ENV['myapp_db_password'] %> encoding: utf8 test: adapter: oracle_enhanced url: <%= ENV['myapp_db_url'] %> username: <%= ENV['myapp_db_username'] %> password: <%= ENV['myapp_db_password'] %> encoding: utf8 production: adapter: oracle_enhanced url: <%= ENV['myapp_db_url'] %> username: <%= ENV['myapp_db_username'] %> password: <%= ENV['myapp_db_password'] %> encoding: utf8 

More information about this can be found in my blog: https://blog.codonomics.com/2011/02/externalizing-all-application-specific.html.