On Sun, Jul 29, 2012 at 10:11 PM, Simon Russell <[email protected]>wrote: > > I also put all the config for my services etc in yaml files in the > config dir, and check in dev versions of the files. The chef stuff > generates deploy-specific versions that are either used directly, or > symlinked in (database.yml being an example of this). I generally > partition them by rails env, but only to keep symmetry with > database.yml -- the only setup that gets used in either staging or > production is the "production" env. >
I dislike this approach as app-specific config (that belongs in the app's VCS, not necessarily chef) can often end up in your config/*.yml files. Example from before that applies to our configuration is database locale. This can easily backfire if your 'devops' isn't as good as it could be - "this app worked until you ops guys replaced our database.yml" > If you do use env vars, you might be better off putting them in an > exec wrapper script so that they're kept in one place. Even if you > are using chef, it's still a possible point of failure/confusion > putting them everywhere. > This is actually what I've done ... chef writes a config/environment.sh file which is pulled in by my shell helper, unicorn, dj, etc. > > Whichever way, I'm pretty sure having worked on the same "explosion of > environments" rails app you have, that keeping the rails envs limited > to "development", "test" and "production" is the only way to go. :) > > +1 -- Michael Pearson -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
