Twelve Factors of Web Application Development
Point 3 - Config:  The claim is that you shouldn't have a config file that you don't check into source control like Rails' config/database.yaml, or the common Django settings_local.py.  Instead you should use environment variables.  Um.  I see the point,but I also see two problems with this.<p>1) I'm certainly not going to set env variables with database passwords and such by <i>hand</i>.  I'm going to have a script to do it for me.  I might even call it, oh, I dunno, settings_local.py.  In which case, I'm right back at square one, needing to not check this into source control.  In other words, how do you avoid having the database passwords in SOME file, SOMEWHERE?  Does it "fix" anything if it's named "fabfile.py" instead of "settings_local.py"?  I can't see how.<p>2) How do I deploy multiple apps to the same server?  Let's say I've got a linode (or EC2 instance, or whatever) running a test, dev, and production deployment of three different apps.  With config files, I just have a different settings_local.py file in each deployments project directory.  With environment variables...what, do I use prefixes?  app1_test_dbpass = 'foo'; app2_prod_dbpass = 'bar', and so on?  Except they say NOT to group stuff together into environments by name.  So uh...how do you manage name collisions?<p>Basically, they seem to have identified a real problem, then proposed a solution that doesn't fix it and doesn't work.  What am I missing?