-1

Working on a huge application with lots of legacy code, I often encounter environment "checks":

db_name = Rails.env.production? ? 'staging_db' : 'production_db'
...
desired_processes_count = Rails.env.production? ? 6 : 1
...
Rails.env.production? ? "index,follow" : "noindex,nofollow"

and so on. It's Ruby on Rails, but I guess the question is applicable for a wider range of projects, despite the technology.

The app does use .dotenv, and in the .env file, there are:

  • credentials
  • hostnames
  • secrets

and that's about it.

In my opinion, readability increases significantly if all of the aforementioned examples:

  • DATABASE_NAME
  • PROCESSES_COUNT (not really readable though, could be more descriptive)
  • SEARCH_ENGINES_INDEXING_DIRECTIVE

are stored as environment variables - it does not have to be .env, obviously, just a single configuration file with all of them.

I am not an expert though.

How can I evaluate if the variable qualifies as an environment variable?

Is there any rule of thumb, set of best practices? Or is it a completely opinion-based question?

1

That is a question of configuration.

Is this aspect of your application requiring information not available at compile time in order to function?

If so expose it through several mechanisms:

  • A Configuration File
  • Environment Variables
  • Command line arguments
  • Interactive Configuration

Which and how much of what is a matter of taste and utility. Generally a configuration file is sufficient with a command line/environment variable pointing to it. Secrets might make more sense stored as environment variables, but again a mater of taste.

If an option is going to be available via multiple interfaces ensuring a common name or addressing style is crucial to avoid confusion.

Similarly if an option can be specified via multiple methods, ensure that those means have a clear order of applicability so that if it is specified several times, only one is considered correct (or an immediate validation error occurs). eg: From least to most relevant: General Config File > Config File Specified by Environment Variable > Environment Variable > Config File specified by Command Line Argument > Command Line Argument > Interactive Response.

Ensure that your application accesses the configuration via a consistent internal mechanism, if you only happens to use environment variables that is fine. Still I would isolate the how from the what to allow for future differences in both what and how.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.