Hacker News Reader

Rails will have custom configuration built-in from 4.2, but you can also just use the gem today: https://github.com/dhh/custom_configuration

Then you can centralize all your configuration in config/environments/* and config/initializers/. The best practice being that you set the configuration in config/environments/ and you read that configuration point and do something with it in config/initializers/*.

IMO, much nicer than messing with ENVs.

View on HN

My first thought after reading the OP, was to link to your blog post[0]. It was a real eye-opener for us, and we stopped using this `if Rails.env.production?` (anti)pattern in favour of configuration. Much cleaner.

I think a key aspect to make this successful is to make configurations 'inherit' from each other (as you explained on the post, using `require Rails.root.join("config/environments/production")`). It really makes our staging environment configuration only very slightly different from production and is very DRY.

[0] https://signalvnoise.com/posts/3535-beyond-the-default-rails...

Do you recommend 'installing' config/environments/* information from a provisioning utility when you're dealing with configuration values that should remain secret and outside of version control?

Reply on news.ycombinator.com