Use local settings instead of environment type variables

2017-01-25

Environment type variables

When you use environment type variables, like:

1
2
3
4
$ export CONFIG=dev
$ export CONFIG=test
$ export CONFIG=stag
$ export CONFIG=prod

you assume that you already know how those environments should be set. You may set a dummy email client, a backend that simulates S3 buckets with local directories, etc.

The problem arises when a developer wants to somehow change that default configuration for something else. They might want to use the real Amazon S3 service instead of a local backend, for example, because he's changing the code of such backend. He might want to change the default value of another variable to test if he can improve the performance of the application, etc. There are many cases in which this is a valid hypothesis.

In such cases, environment variables are in the way. They'll make the developer change the default settings for that environment, and remember to revert the changes back before committing his patch.

Local settings

A much better approach is using local settings. With local settings, you provide in your repository a recommended initial configuration for fellow developers to use when starting to work. They create a copy of such file with the appropriate name and point the application to use it as its configuration, but then afterwards, they are free to modify the copy and change the configurations to what is best for them.

Usually, you'll also want to:

  1. Document this behavior, so developers know what file to copy, and how to point the application to use such file;
  2. Have configuration files ready for the environment that are preset, like the staging environment and the production environment. Since these often contain secret variables, like passwords and authentication tokens, you'll probably want to, either, store them at a separate repository or fetch the values from environment variables that you set at those environment runtimes.