`envdir` [1] is a common pattern for maintaining environment with a directory of key/value files.

If you use `foreman` [2] to manage application process formations, it will source a '.env' file before running.

You could call either pattern a "config file" but the important part is that its actual Unix environment variables, and there is a safe and secure place to store the variables outside of the code repository.

Then... you can take a huge leap forward when running on Heroku. Heroku has an API to set environment variables:

  $ heroku config:add API_PASSWORD=abc123

That value will be present in the runtime environment for the life of your application. So you do enter them manually -- but only one time when setting up an app.

The really clever part is that 3rd party add-on providers can also set environment variables on your app with a similar API. So if your database is an add-on:

  $ heroku addons:add redistogo
  $ heroku config
  REDISTOGO_URL => redis://user:pass@host-1:9492/
  
  $ heroku addons:upgrade redistogo:medium
  $ heroku config
  REDISTOGO_URL => redis://user:pass@host-2:9133/

If settings are in config files, you would have to deploy new code to change settings, and you wouldn't have a way for your hosting platform to help manage settings.

[1] http://cr.yp.to/daemontools/envdir.html

[2] http://ddollar.github.com/foreman/

In a well run environment there are generally special tools that can provision a new node, generally these kind of environmental configurations are set up there. Some people do manage it in source control and just have a branch for each environment. Both work, but one provides an avenue to offload the task from a developer onto an infrastructure type role.

The choice of a config file and/or environment variables seems more sensible.

I personally am not a fan of config files at all, a lot of this stuff comes down to preferences and experiences, but I have seen the environmental configurations being put in config files problem repeated over and over, then someone checks in the config with the project and someone checks it out and then it gets installed in an environment. It is considered good practice to separate configuration data from the code entirely, so that a commit, with config files, to source code cannot blow up an environment. Many recommend, as is the case with this author, that that separation happen by putting the config in environmental variables, that way it is wholly separated from the application and an updated to the application cannot blow up an environment. I agree with the conclusion and through experience, have found it to be the best solution as well. That beings said, using a tool like Puppet to automate and turn over, the process to infrastructure, is pretty simple, but some groups don't like to use tooling and if not, having an environmental configurations script in a separate repository, is just as valid of a process and will reduce the failure point.

I've arrived at the same conclusion recently, at least as far as keeping production configuration out of config files and putting them in environment variables instead. I'm curious, what is your take on configuration for the development and test environments?

I'd prefer that a project can be set up for development as quickly as possible, so my current approach is to check in default configurations for the development environment that are overridden with environment variables in production.

It depends on the technology that you use but many runtime environments allow the IDE to provide environment like configuration in the project properties, I tend to like to use that approach over specialized config files because the project files are wholly separate from the code base. For example the JVM allow you to send flags to it on initialization, Netbeans and Eclipse provide an interface to manage those flags from a development perspective, to the JVM they look no different than environmental variables and therefore the absence of the project files means that it transparently gets that configuration from the environment. I am a fan of that solution over specialized config files that are developed by the development team.

Two questions. 1) Do you do that for everything? Including database and memcached connection settings, cache settings, basically everything that's configurable about a web app? I'm not an IDE user nor familiar with Java, so that's a serious question. 2) How do new developer's get an environment set up quickly?

1) yep, everything, the code can hit an environment and run based on that environment. No configuration is provided with the code. That being said how you implement it can be pretty flexible you could separate them all out into separate variables or just have one variable with an XML string as the value and parse that string to get configuration, the point is to have the configuration injected into the application by the environment. The details of what those variables look like is the prerogative of the development team.

2) there are several options, a developer (gold CD) virtual is one, where a virtual is set up and configured based on updated configuration and an automated script, or having a environmental script that sets up the development variables on the developers workstation (just make sure it stored in version control independent of the code). Each works well, it just depends on preference, there are a lot of ways one can set it up to work in their environment, just try a few and see which one best fits your development culture.

Thanks. I'm definitely on board with #1. I'm still trying to figure out what will work best for me for #2. It's interesting (and useful) to hear how others solve it.

yeah, I'm not a fan of using environment variables. Using symlinks has always seemed more stable to me.