Hi, I think there are a lot of good reasons to use multiple environments. Of course a staging, integration or sandbox environment should be as close as possible to production, but only close and not equal.
For instance log level, filter parameter, asset host comes into my mind. To name only a view different things. Of course you can configure all this via environment variables. But in my point of view this belongs to the application. To configure this details via environment variables is not as clear as the environment rbs. Furthor more I want to have different environment variable names for production environment and the rest. Simply as a kind of safety net and fast indicator when I inspect envs within my console. Also is RAIL_ENV=staging rake ... instead of RAIL_ENV= production rake ... some thing to prevent a big mistake just in case I did choose the wrong console. I would opt for different environments. Even if it mean a huge overhead to keep this environments in sync. To me environment variables make only sense for secret things, config options which change often or options you want to be able to change without a redeployment. Regards Dieter Am 2. März 2017 22:55:41 MEZ schrieb richard schneeman <[email protected]>: >I highly recommend against "custom" environments. > >I disagree with using environments for configuration (such as database >connections), they should be used for behavior. > >Here's a thing I wrote about the problems you can get into by solving >problems by creating new "env" >types: >https://devcenter.heroku.com/articles/deploying-to-a-custom-rails-environment > >While i'm talking about "staging" as an env, I think it's generally >applicable to any non development/production/test environments. > >I also don't think the problem you're trying to solve with a custom >environment is fully formed. I've not found a need for a custom test >like environment. > >-- >Richard Schneeman >http://schneems.com > > >On March 1, 2017 at 7:36:22 AM, Chad Woolley ([email protected]) >wrote: > >See also this thread: > >https://groups.google.com/d/topic/rubyonrails-core/kqKoJHcQu9U/discussion > >...wherein is discussed (without any official response from core >contributors) many of the warts and limitations of RAILS_ENV in a >modern, cloud-native-y, 12-factor-y world. > >-- Chad > >On Mon, Feb 27, 2017 at 6:15 AM, Vijay Raghavan Aravamudhan ><[email protected]> wrote: >With the latest merge into the master branch of this >https://github.com/rails/rails/pull/26703, it seems that the core >framework is heading in a direction where functional/system tests are >also being accepted in a more formal way. If this is the case, imo, it >would make sense to also have a RAILS_ENV that is separate from the >ubiquitous 'test' env. In all my RoR projects where we have written >automated functional tests using some framework, we have had to >duplicate 'test' into something else. Would the community think that >such a formalization makes sense? > >tx, >Vijay >-- >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. > >-- >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.
