Thanks for sharing that article. I agree that app deployment could benefit
from Rails' convention over configuration philosophy.
There may be some low-hanging fruit for new apps, though. For example,
here are a few of the things on my to-do checklist before deploying a new
app for the first time:
1) Modify database.yml to use ENV["DATABASE_URL"] in production.
2) Set Rails.application.default_url_options[:host] in production.
2b) Set `Rails.application.default_url_options[:host] = "localhost"` and
`[:port] = "3000"` in development and test.
3) Set `Rails.application.config.force_ssl = true` in production.
3b) Set `Rails.application.default_url_options[:protocol] = "https"` to
match force_ssl.
4) Set `Rails.application.config.action_mailer.default_options[:from] =
"no-reply@#{Rails.application.default_url_options[:host]}"`.
Rails might be able to take care of these things for new apps,
out-of-the-box. To elaborate...
1) The default database.yml mentions ENV["DATABASE_URL"] in a comment, but
uses :database, :username, and :password placeholder values instead. Maybe
these could be swapped, i.e. use ENV["DATABASE_URL"] by default, and
mention in a comment the option of setting values individually. Or,
possibly use ENV["DATABASE_URL"] with an interpolated fallback string, e.g.
`url: <%= ENV['DATABASE_URL'] || "..." %>`.
2) Maybe Rails could designate an official environment variable that would
populate default_url_options[:host], e.g. ENV["APP_DOMAIN"] or
ENV["APPLICATION_HOST"]. This does shift the problem from modifying a
Rails config file to setting an environment variable, but perhaps,
eventually, deployment scripts and hosting providers (e.g. Heroku) could
standardize and take care of that automatically.
2b) A default default_url_options[:host] in development and test would
allow url_for (et al) to just work when previewing or testing mailer
templates.
3) In a post-Let's Encrypt world, `force_ssl = true` might be a reasonable
default. Heroku also offers free SSL certificates on paid dynos, as does
AWS if you use an Elastic Load Balancer.
3b) There is an open PR for force_ssl to affect
default_url_options[:protocol]: https://github.com/rails/rails/pull/23543
4) default_options[:from] also affects gems that send mail, like Devise.
So providing a default potentially saves multiple extra steps of
configuration. And "no-reply" seems like a standard choice.
On Sunday, January 13, 2019 at 1:10:31 PM UTC-6, 姜军 wrote:
>
> I found this article from RubyInside:
>
>
> https://medium.com/@wintermeyer/https-medium-com-wintermeyer-rails-needs-active-deployment-65c207858c3
>
> I think the article is reasonable, and I saw DHH removed Capistrano from
> Rails 6 Gemfile.
>
> I know it's difficult, but is there any chance to abstract deployment into
> "Active Deployment"? or after removing Capistrano, which way is Rails team
> suggests?
>
--
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 rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
