Ответ 1
Вот отличная запись в блоге от ребята по поводу этого. Я взглянул на него, но не прошел через шаги в производстве.
http://blog.codeclimate.com/blog/2013/10/02/high-speed-rails-deploys-with-git/
Для Rails 3, этот вопрос и turbo-sprockets-rails3 отлично смотрятся.
Для Rails 4 кажется, что некоторые разногласия относительно того, было ли это исправлено или нет.
В настоящее время я использую Rails 4 в производстве, и кажется, что, поскольку Capistrano deploy:assets:update_asset_mtimes
затрагивает все активы, deploy:assets:precompile
также перекомпилирует все из них. Эта перекомпиляция является единственным самым длинным шагом в моей cap deploy
.
В идеале это должно быть заменено некоторой системой манифеста, основанной на контрольной сумме, так что только те активы, которые фактически изменились (или зависят от измененных), повторно скомпилированы.
Каков наилучший способ сделать это? (Предполагая, что мы все еще делаем это на сервере, а не на машине dev.)
Вот отличная запись в блоге от ребята по поводу этого. Я взглянул на него, но не прошел через шаги в производстве.
http://blog.codeclimate.com/blog/2013/10/02/high-speed-rails-deploys-with-git/
Этот парень получил это право для Capistrano 3. Хорошо работает для меня. https://coderwall.com/p/aridag
Этот вопрос обсуждался в https://github.com/capistrano/capistrano/issues/478 и решение, которое, похоже, в порядке, - это просто отключить прикосновение. В вышеизложенной проблеме говорилось о переменной конфигурации для использования для этого, но я не мог найти ссылок на нее кодом. Вместо этого мы просто перезаписываем задачу.
namespace :deploy do
namespace :assets do
task :update_asset_mtimes, :roles => lambda { assets_role }, :except => { :no_release => true } do
end
end
end
Примечание. Это справедливо только для capistrano версии 2. Я понятия не имею, поддерживает ли версия 3 одни и те же задачи или нет.