I think we have a common opinion in many points, but not in all. I don't
know if this is all off topic, but I like to drive this discussion a little
bit further.
First we should clarify some words. This is how I understand the terms. We
talked about "behavior". It is what and how the
I think I lost you on my example of running the RAILS_ENV=production code
locally & why it was safer without production config info checked in.
In my case I'm using a `.env` file and already have all the creds I need for
local development i.e. stripe API token and AWS etc. They're all set for
>
> I'm less concerned about how often you need to change the config var, but
> more concerned about how sensitive it is and how bad would it be if you
> used the wrong thing in the wrong place.
>
>
Yes, I agree. If an information is sensitive should be the first indicator,
to exclude it
> To me environment variables make only sense for secret things
A "secret" thing should be your database connection or redis credentials. I
consider this "configuration".
> config options which change often or options you want to be able to change
> without a redeployment.
I'm less concerned
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
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:
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,
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
