> > 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 from your version control system. But in my point of view when you have a large old monolitc application which takes a a lot of time build, you also take into account if you want to re run your hole chain just for a change in a setting.
> > > Most people who are running a "staging" environment will have > `RAILS_ENV=staging` in the environment (via bash profile or config vars on > Heroku). Most people would just run `rake db:drop` (or whatever) without > specifying the `RAILS_ENV`. So in the case you're in the wrong console, > you're screwed because `RAILS_ENV=production` would be set. > > It's like every precaution, you can use or not. I think you can compare it to sudo with password or passwordless. It's up to you how you use it. But it's good if it is available. > If you're using production & staging "environments" what can happen is > you're debugging some strange behavior and you accidentally do something > like `export RAILS_ENV=production` to see if it matches the behavior in > staging, then you run `rake db:drop` a few seconds later then, oops you > just dropped your production database. > My my fault I didn't explain how I use it. For instance I have an env STAGING_DB... and PROD_DB ... . Within my staging environment PROD_ is not set and my staging server has no connection to my production systems. > Why did your staging app need access to your production database > credentials? It didn't and should have it. If you were storing that data in > the env instead of on disk via a config file you wouldn't have hit that > problem. > Your right, but a DB connection contains passwords and so on and does belong into an env. Like I said, my staging differ in behavoir for instance how it logs, what it logs. > > > I think it should have the exact same behavior. The point of staging is to > be able to tell if things will work in production. So if it has slightly > different behavior, it's not a reliable indicator of if production will > work. I'll give you an example. > > In this point I disagree a little. I agree you can experince issues with production environment you do not experince with staging, intigration or sandbox. For this it should only differ as slightly as possible. But for instance logging I want in this environments more verbose then in production. So I can nail down an issue faster. > I had a customer who had a bug with the asset pipeline in prod but not > staging. It turns out have weeks of debugging they had view caching enabled > in prod but not in staging which was causing an old link to an asset to be > shown on production, but the bug didn't reproduce on staging. This is an > area where staging should have seen the bug but the __behavior__ was > different. Prod and staging should have the same behavior. > If you have experience with Rails, then you know that such things can happen. I did experince such kind of errors, but after a short while you try it with a "faked" production environment. > > Where they differ should be config. They should not have the same log > level, should not share the same database, should not be using the same > redis instance, or should not be using the same CDN. There can be unsafe > things such as charging a customer's card, in that case > stripe/paypal/whatever all have "developer" or "test" API tokens that you > should be using in staging. If you're worried about sending emails, you > should be using a different account or something like a mail catcher > service. > In my point of view when your config is mostly static and not sensitive, it belongs into an environment rb and not an environment variable. It is easier to take a look into my source code for a configuration instead of connecting to a server and check the environment variables. And least source code is controled by the developer. Environment variables are controled by the operator. This persons can be the same but must not. > > > It's a false sense of safety and actually makes it easier to mess up > things. > > For instance I was looking at a friend's app recently and was trying to run > https://github.com/schneems/derailed_benchmarks (which I wrote). You > profile your app locally and to do this accurately you need to do it with > RAILS_ENV=production. We were about to hammer an endpoint when we > remembered that there were some config (such as billing backend) hard coded > into the app. > > So now we can't run benchmarks locally, or if we try we might accidentally > manipulate production data. > Sorry, I don't get it. This can happen with environment variables too.I don't see the false safety. > > Even if you're not using performance profiling sometimes bugs only show up > in RAILS_ENV=production that you need to test locally. If you're checking > all your config into your app's source that becomes a very dangerous task. > Like I said. Not all config. You have to consider carefully which belongs to a config file and which to an environment variable. But that's every time the case. > If you have all your dangerous things decoupled away from RAILS_ENV then > it becomes a very safe task. > I don't think so. You still can issue a command within a wrong console and all is set up. When you don't export RAILS_ENV and set it with every command, then you get a tiny little more safety, as long as you don't use copy & paste. > > RAILS_ENV is for behavior, configuration is for secrets. I've seen a huge > number of cases where tying behavior and configuration together causes many > many problems, and decoupling them solve many many problems. > It's like every thing. You have to find the right balance for your specific problem. > > Where am I coming from? > I work since 2007 with Ruby and Rails. The last 5 years I did develop RoR applications in a professional environment. > I work from Heroku and have debugged literally thousands of Rails apps > over the last 5 years. After writing that article and adding a warning to > buildpack deploys I saw a significant drop in the number of support tickets > opened on the platform. At one point is was the largest cause of customer > tickets. I acknowledge separating behavior (RAILS_ENV) and config on > non-heroku platforms is harder because the infrastructure for env-vars > isn't as easy, but the benefits are no different. > Heroku is in my point of view a special environment because you can only use environment variables to configure things. For instance you can't generate config file during deployment or do other stuff. Furthor more (realy opinionated meaning, can be realy wrong) I think most of your tickets came from RoR starters and not long term Rails users. > > -- > Richard Schneeman > http://schneems.com > > > On March 2, 2017 at 2:34:38 PM, Dieter Späth ([email protected] > <javascript:>) wrote: > > 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. > > -- 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.
