4 ms·

As far as I can see this article is rather misguided. The author seems totally unaware of the existence or purpose of these files: config/environments ├──

by venus 14y ago

As far as I can see this article is rather misguided. The author seems totally unaware of the existence or purpose of these files: config/environments ├── config/environments/development.rb ├── config/environments/production.rb └── config/environments/test.rb Put all this stuff in there. edit: I see the source of this misunderstanding. The author states: > Rails applications should be “turnkey”; that is, deployed anywhere without modifying code This is an ideological statement with no basis in reality. If you have to jump through all these hoops in order to trick your app into running as expected without modifying code - you're probably Doing Things Wrong™. A better approach might be to make a private fork of the project you wish to deploy, modify the code as needed, deploy from that, and periodically merge from upstream.

graue 14y ago
I've been reading "The Twelve-Factor App" today, which goes even farther and suggests a strict separation of code and config[1]. In which case, presumably, all of these settings: config.action_mailer.smtp_settings = { address: "smtp.gmail.com", port: 587, domain: "example.com", authentication: "plain", enable_starttls_auto: true, user_name: ENV["GMAIL_USERNAME"], password: ENV["GMAIL_PASSWORD"] } would be stored outside the codebase, not just the username and password. This seems to be accomplished with a tool like Foreman[2], mentioned at the end of OP under "Other Approaches". It's more work to set up, but does seem like it would be more reliable than your method. I like the idea of deploying an app anywhere without modifying code (only config details, stored separately). I've yet to work on a large SaaS app, but am studying the 12-factor manifesto to try to implement as much of it as possible when I do. [1] http://www.12factor.net/config http://www.12factor.net/config [2] https://github.com/ddollar/foreman https://github.com/ddollar/foreman
- venus 14y ago
  I read the "Twelve Factor" article you linked to and .. well, I just disagree. > A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials This to me is a totally arbitrary and kind of silly "test". When was the last time you had to suddenly open-source an app you were working on? Never, right? Me neither. Why would I go to all this work to keep it "instant open-source ready"? > As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config As a senior rails dev + team leader, the way I'd handle this is to tell "joe" not to commit his local junk to the repo. Otherwise I have never seen this "explosion" happen. I would certainly not go to all this effort - and introduce all this complexity - to work around what I consider to be an educational issue. The whole 12-factor config thing just comes across as premature optimisation. If you actually find yourself having a problem that putting config in environment variables would fix - then fine, implement it. But no-one should be doing it up front. 99% of the time, you ain't gonna need it.
asfdfdasfafdsss 14y ago
Agreed. Certain things are fine to do w/env. vars. but as you mention, the need for their use is much more infrequent than is suggested in this post. Additional things to think about: * https://github.com/railsjedi/rails_config https://github.com/railsjedi/rails_config for local developer config * There is a reason for autoloading: faster development. Even though you should not usually need to make app-specific configuration changes outside of the main environment.rb and each environment-specific config (development.rb, etc.), if you do, you might consider putting them into a module in an autoload path, and make sure that the fully-qualified path (A::B::C maps to something like app/models/a/b/c.rb) is correct, so that it autoloads without trouble. * Some suggest putting constants for frequently used values in a file somewhere under config/initializers. That way Rails doesn't complain when reloading them. But, that doesn't autoload if you make changes in development. * You can extend a Module that is autoloaded with methods that are "marked" with module_function :method_name to become private class methods on the class that extends them. This way you have non-inheriting methods that basically act like config variables. * You can just use class_attribute in Rails to define inheritable attributes and then use self.the_class_attr_name = something to set them in the body of the class for configuration. * attr_accessor :some_var_name, @@some_class_var, @some_instance_var, a hash, a Struct, or a OpenStruct are fine ways to hold config values and can be set inline for class vars, in the initialize method for instance vars, or methods called by other hooks, depending on what you need. * Usually avoid $some_global_var as there is no way to tell whether it has been defined nor whether it has been set explicitly to nil.
- jacquesc 14y ago
  author of rails_config here. rails_config is sort of nice because you can use ERB so mix your regular settings along with ENV settings That said, it's not been a terribly well maintained project. Haven't had time, needs help! I still use 0.2.5 since that's the only one that works for me :)
freerobby 14y ago
I much prefer the ENV method because it keeps private keys and passwords out of source control.

by venus 14y ago

graue 14y ago

I've been reading "The Twelve-Factor App" today, which goes even farther and suggests a strict separation of code and config[1]. In which case, presumably, all of these settings: config.action_mailer.smtp_settings = { address: "smtp.gmail.com", port: 587, domain: "example.com", authentication: "plain", enable_starttls_auto: true, user_name: ENV["GMAIL_USERNAME"], password: ENV["GMAIL_PASSWORD"] } would be stored outside the codebase, not just the username and password. This seems to be accomplished with a tool like Foreman[2], mentioned at the end of OP under "Other Approaches". It's more work to set up, but does seem like it would be more reliable than your method. I like the idea of deploying an app anywhere without modifying code (only config details, stored separately). I've yet to work on a large SaaS app, but am studying the 12-factor manifesto to try to implement as much of it as possible when I do. [1] http://www.12factor.net/config http://www.12factor.net/config [2] https://github.com/ddollar/foreman https://github.com/ddollar/foreman

venus 14y ago
I read the "Twelve Factor" article you linked to and .. well, I just disagree. > A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials This to me is a totally arbitrary and kind of silly "test". When was the last time you had to suddenly open-source an app you were working on? Never, right? Me neither. Why would I go to all this work to keep it "instant open-source ready"? > As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config As a senior rails dev + team leader, the way I'd handle this is to tell "joe" not to commit his local junk to the repo. Otherwise I have never seen this "explosion" happen. I would certainly not go to all this effort - and introduce all this complexity - to work around what I consider to be an educational issue. The whole 12-factor config thing just comes across as premature optimisation. If you actually find yourself having a problem that putting config in environment variables would fix - then fine, implement it. But no-one should be doing it up front. 99% of the time, you ain't gonna need it.

asfdfdasfafdsss 14y ago

Agreed. Certain things are fine to do w/env. vars. but as you mention, the need for their use is much more infrequent than is suggested in this post. Additional things to think about: * https://github.com/railsjedi/rails_config https://github.com/railsjedi/rails_config for local developer config * There is a reason for autoloading: faster development. Even though you should not usually need to make app-specific configuration changes outside of the main environment.rb and each environment-specific config (development.rb, etc.), if you do, you might consider putting them into a module in an autoload path, and make sure that the fully-qualified path (A::B::C maps to something like app/models/a/b/c.rb) is correct, so that it autoloads without trouble. * Some suggest putting constants for frequently used values in a file somewhere under config/initializers. That way Rails doesn't complain when reloading them. But, that doesn't autoload if you make changes in development. * You can extend a Module that is autoloaded with methods that are "marked" with module_function :method_name to become private class methods on the class that extends them. This way you have non-inheriting methods that basically act like config variables. * You can just use class_attribute in Rails to define inheritable attributes and then use self.the_class_attr_name = something to set them in the body of the class for configuration. * attr_accessor :some_var_name, @@some_class_var, @some_instance_var, a hash, a Struct, or a OpenStruct are fine ways to hold config values and can be set inline for class vars, in the initialize method for instance vars, or methods called by other hooks, depending on what you need. * Usually avoid $some_global_var as there is no way to tell whether it has been defined nor whether it has been set explicitly to nil.

jacquesc 14y ago
author of rails_config here. rails_config is sort of nice because you can use ERB so mix your regular settings along with ENV settings That said, it's not been a terribly well maintained project. Haven't had time, needs help! I still use 0.2.5 since that's the only one that works for me :)

freerobby 14y ago

I much prefer the ENV method because it keeps private keys and passwords out of source control.