All,
I've run into a few cases recently where I have environments that are
nearly (or totally) identical, except for the database. For example, I
have a "live" environment locally where I pull production data for
load testing or triage, and I generally want it to behave like
"development". Similar situations occur for continuous-integration or
staging boxen that should look an awful lot like development (or
production), but not quite.
In order to make these sorts of situations pleasantly
self-documenting, I've patched the Initializer with a little helper:
# config/environments/live.rb
acts_like :development
Is this a patchworthy feature? I'd be happy to submit my change and
tests if other people see any value here. As this changes Rails'
initalization process, it's a bit difficult to elegantly expose as a
plugin.
~ j.
I've run into a few cases recently where I have environments that are
nearly (or totally) identical, except for the database. For example, I
have a "live" environment locally where I pull production data for
load testing or triage, and I generally want it to behave like
"development". Similar situations occur for continuous-integration or
staging boxen that should look an awful lot like development (or
production), but not quite.
In order to make these sorts of situations pleasantly
self-documenting, I've patched the Initializer with a little helper:
# config/environments/live.rb
acts_like :development
Is this a patchworthy feature? I'd be happy to submit my change and
tests if other people see any value here. As this changes Rails'
initalization process, it's a bit difficult to elegantly expose as a
plugin.
Can't you just require common pieces of code from each of the
environments? If not, perhaps we should make that simpler to do.
The initializers feature also takes care of a lot of the duplication I
used to have between 'production' and 'staging' at present, what
stuff are you left with in both files?
> # config/environments/live.rb
> acts_like :development
Can't you just require common pieces of code from each of the
environments? If not, perhaps we should make that simpler to do.
In the case of two environments that share common pieces of code,
absolutely. Where I've found this most useful, though, is in a case
where an environment is either *precisely* the same as another (except
for the database, e.g., running with a copy of live data on your local
dev machine), or differs in the most minor of ways.
This is really just a bit of sugar, of course. It's the equivalent of:
# in config/environments/live.rb
# live should act exactly like development, except for the database
eval(IO.read("#{RAILS_ROOT}/config/environments/development.rb"))
As sugar, it may not be a good addition. I sure think "acts_like
:development" is nice, though.
The initializers feature also takes care of a lot of the duplication I
used to have between 'production' and 'staging' at present, what
stuff are you left with in both files?
Love the initializers. Leftover differences between, say, production
and staging are mostly totally reasonable stuff, like email addresses
or server names/IP's.
~ j.
In the case of two environments that share common pieces of code,
absolutely. Where I've found this most useful, though, is in a case
where an environment is either *precisely* the same as another (except
for the database, e.g., running with a copy of live data on your local
dev machine), or differs in the most minor of ways.
Couldn't you achieve this with symlinks though?
Absolutely. The only reason I can think of to use something like my
acts_like sugar instead of symlinks is clarity and maintainability
over time: I think it's good that anybody who cats/edits the file will
immediately know that it mirrors another environment, which isn't
necessarily the case with a symlink. We're all moving at lightspeed
'round here, and the more explicit information the better. Symlinks
aren't sneaky, but they're certainly not always obvious.
That said, the combination of initializers and symlinks makes my
justification pretty thin. 
~ j.
