Ruby apps best practices
Closed this issue · 8 comments
For consideration, see
http://blog.howareyou.com/post/66375371138/ruby-apps-best-practices
Thanks @darrenleeweber. That's a new one for me. I'm not sure how prevalent those patterns are in the wild. I have seen that rubygems is now injecting bin/setup and bin/console into new gems though (that said, they are different from the ones given in that post..)
The only other example of bin/test I've run across is promoted by the possibly defunct https://github.com/rubyworks/rubytest
To me, it makes more sense to use e.g. rake to get into the Ruby VM faster, where it should be easier to get more predictable builds (e.g. to isolate ourselves from platform- or environment-specific problems)
In effect, the main issue here is whether or not to use system environment variables to configure apps. The pro argument is related to separation of app vs. dev-ops/deployment operations; the argument con is related to app control over configs, regardless of system ENV. So, it may depend on what side of the fence you reside: dev vs. dev-ops. In my code for DLSS/LD4L, the projects have adopted the ENV config approach, with the app/gem providing fallback defaults, so those code projects should be dev-ops/deployment friendly. This assumes that deployment systems use ENV to configure apps, which is partly true (e.g. Apache Passenger has configs that set RACK_ENV and/or RAILS_ENV and those values can determine app behavior). See also #6, esp. http://12factor.net/config
On sul-dlss/spotlight, sul-dlss/searchworks, sul-dlss/earthworks (and others?), we've successfully used https://github.com/railsconfig/rails_config to provide the environment configuration. In addition to the environment-specific YAML configuration, you can also override those defaults using ENV-style configuration.
Using the settings.yml approach is attractive to me because, at the very least, it:
- provides a (consistently located) registry of properties used in the application
- can provide reasonable defaults for some common, environment-specific (yet not sensitive) properties
- easily isolates your tests from the system environment, making for tests that are easily reproducible in all environments
I'll also note (and, @sul-dlss/devops, correct me if I'm wrong..) we don't typically handle environment-based configuration for webapps. I believe most of our applications use YAML configurations, with environment-specific information marked as capistrano shared files.
What if the code repository is not a rails app (or similar web-app)?
👎 this is too broad and vague for me. Particularly since our meeting on 2015-05-21 -- I don't even know what I'd be voting on here.
@cbeer - I'd like to see a blog post or a dev-meeting demo of what you describe above, "On sul-dlss/spotlight, sul-dlss/searchworks, sul-dlss/earthworks (and others?), we've successfully used https://github.com/railsconfig/rails_config to provide the environment configuration. In addition to the environment-specific YAML configuration, you can also override those defaults using ENV-style configuration."
Bulk closing inactive issues. Feel free to reopen as needed.