+1 on at least discussing what can be done about this. The dev-env-switching-to-test thing has caused me lots of headaches over the years, including in areas other than the db handling mentioned here - the most recent coincidentally being today.
Another way to think of the problem is that on local dev environments, you default to "development" whenever you run rake or start up the app, but it's normal practice for CI environments to hardcode their container environments to "test". That sets up a built-in opportunity for problems due to different behavior on CI than on local dev boxes - especially for any config value that is different between dev/test env, but is persisted (e.g. setting environment variables) between the Rakefile invocation and the test helper switching the ENV to test. When you get more complex apps and situations, e.g. Procfiles for various environments which start multiple processes, and nested scripts/rake tasks/test suites, especially ones like cucumber/integration that need to precompile assets on the fly but maybe not start up services, it can be hard to sort out what config values came from where, and why. The 12-factor app guidelines (http://12factor.net/config) are correct in saying that you should try to be environment agnostic, but also valid criticism of its omissions/vagueness/hand-waviness in this area: http://cloudfactor.io/factor/three/ I'm not sure what the fix is, but in general moving away from fixed "environments" to more granular config values seems good. This could look something like: * Deprecating the use of Rails.env and RAILS_ENV * Assuming that development is no different than any other non-test environment, move all config settings from generated development.rb to be conditional/commented entries in application.rb, and allow/require people to override them as appropriate for their current environment. E.g. * Likewise requiring test- specific code or libraries that currently rely on setting/checking test environment to instead directly read or set granular Rails configuration values. For example, people or libraries could set env vars (just examples, but you get the idea) RAILS_EAGER_LOAD or RAILS_ACTION_CONTROLLER_PERFORM_CACHING before app startup to override any defaults in application.rb, and (admittedly hard, alotofwork, or impossible in some cases) libraries could also override values on the fly after initialization as appropriate. That would be a big change with lots of ripples, but definitely a move in the right direction in an increasingly cloud-native 12-factor-ish world. Thanks, -- Chad On Sun, Jan 10, 2016 at 10:50 PM, Vladyslav Hesal <[email protected]> wrote: > Although this thread started to me from the single bug (unexpected > "feature") I want to address the issue more widely. > > There is a methodology (approach) to develop portable, scalable and > maintainable web-services called "The Twelve-Factor App". On of it's > "factors" is the environment agnostic approach to configuration (although > it is not called so explicitly in the document, I think this two words > expresses the sense): http://12factor.net/config > > It is almost possible to be environment agnostic with Rails. But there are > some issues. > The issue I mentioned is this: > https://github.com/rails/rails/blob/3ba176d0a07728e9505609967b518d85129bff24/activerecord/lib/active_record/tasks/database_tasks.rb#L282 > And here is some consequences: > https://github.com/laserlemon/figaro/issues/225 > > Rails tries to be in two environments in a single run. It looks bad. It's > surprising. It prevents effective environment management (homogeneous > config applicable to any environment). > > What do you about environment agnostic approach and about it implicit > support by Rails (e.g. everything works if you doesn't mention any > environment enywhere in your project)? > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
