Does anyone know what's wrong with the Rails asset pipeline that is mentioned in the post as one of the issues?
I'm also of the opinion that compiling assets in production as a part of your deployment process is insane, there's so much magic in the Rails asset pipeline that it's not uncommon to turn up bugs where tables don't exist, and the rails app can't initialize, or some javascript runtime environment isn't found which can leave your deployment in a broken state.
I'm firmly of the opinion that assets should be compiled and checked in, but then of course you run into problems with rails serving those in development mode, rather than the development files.
All these issues are fixable, but they're all indicative of tools that aren't quite mature yet, and as Capistrano sits on the boundary of where these problems come to light, it seems to fall to us to deal with it, and to educate people on what they ought to be doing.
Education is no problem, I really believe that the de-facto standardisation of Rails-like deploys (i.e timestamped releases, with common linked directories, and a symlink to the current active timestamp) is an excellent result for knowing what to expect in an environment where there's hundreds of ways to get Rails apps running, but it's still not as smooth a process as it could be.
I'm familiar with at least one project that's been re-written in Scala and Java because the previous version was prohibitively difficult to deploy as it was in RoR. (GrayLog2, to namedrop them)
> some javascript runtime environment isn't found
As someone coming from Java (I largely switched from Java to Rails about a year ago) I find this tendency toward native code deps incredibly painful. Turns out there's a really good reason to demand "100% pure Java" libraries. One can always throw rocks at Maven or CLASSPATH hell, but I find that Ruby deploys tend to be much more problematic than Java.
Whatever you decide on I hope you get some relief. FWIW I have benefited greatly from your work on Capistrano, and sincerely appreciate your efforts.
This is one of the pain points for me. Even when everything is setup, the asset compilation churns the disks and takes way too much cpu. I would rather do that on my local machine than disrupt the production server. I do a simple workaround for that:
namespace :deploy do
namespace :assets do
desc 'Run the precompile task locally and rsync to shared'
task :precompile, :roles => :web, :except => { :no_release => true } do
run_locally "rake assets:precompile"
run_locally 'rsync -e "ssh -i production.pem" --recursive --times --rsh=ssh --compress --human-readable --progress public/assets #{user}@#{host}:#{shared_path}'
run_locally "rake assets:clean"
end
end
end # Dont recompile assets unless they hange
task :precompile, :roles => :web, :except => { :no_release => true } do
from = source.next_revision(current_revision)
if capture("cd #{latest_release} && #{source.local.log(from)} vendor/assets/ app/assets/ | wc -l").to_i > 0
run %Q{cd #{latest_release} && #{rake} RAILS_ENV=#{rails_env} #{asset_env} assets:precompile}
else
logger.info "Skipping asset pre-compilation because there were no asset changes"
end
end
For me, the more important thing was not compiling on a production box. Compiling on production box does lots of io and uses way too much cpu. I am ok with a slight delay in deploy due to assets compilation happening on my local machine.
I see a lot of people in this thread criticizing the assets pipeline. But I think it's a good idea with an implementation which is yet to mature. For now, it needs some work on my part(do I check in the assets, do I compile on production box, how do I ensure assets are only compiled when changed etc etc), but overall I am quite happy with the way it works.