For future reference (and for others), another option is Settingslogic: https://github.com/binarylogic/settingslogic
The nice thing about settingslogic is that you can namespace the settings however you want, and can also create dynamic settings as necessary (settings dicated by more complex logic than what can be found in a YAML file). The idea would be to gitignore your settings YAML file and copy it during deploy. I typically manage this within Capistrano - not sure how this would be done with Heroku. Cheers, Rohan On Wed, Dec 14, 2011 at 2:04 PM, Chris Radcliff <[email protected]> wrote: > Thanks for all the suggestions. I ended up going with a modified > version of the "Heroku way", which seems to provide the most > flexibility when deploying. > > Specifically, I'm using ENV variables for secrets, like this chunk in > environments/production.rb: > > ActionMailer::Base.smtp_settings = { > :address => "smtp.sendgrid.net", > :port => 25, > :authentication => :plain, > :user_name => ENV['SENDGRID_USER'], > :domain => ENV['SENDGRID_DOMAIN'], > :password => ENV['SENDGRID_PASSWORD'], > } > > I added a shim for cases (like nginx + Passenger) where passing ENV > variables is unwieldy. It's just another file included in > application.rb: > > secrets_file = File.expand_path('../too_many_secrets', __FILE__) > require secrets_file if File.exists?(secrets_file + '.rb') > > That way I can include a .template.rb file next door as a list of > secrets the app needs to know about. > > Comments and refinements are welcome. Thanks again for the suggestions. > > ~chris > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
