3

I am struggling with the idea of deploying a large app using the the asset pipeline and the precompile Capistrano task.

  1. I don't want to install the javascript runtime environment and precompile the assets on each production server.

  2. The assets need to be uploaded to two Nginx servers that don't have a copy of the app.

So I have created a Capistrano task that precompiles the assets locally and then uploads the assets to the the Nginx servers, and the manifest files to the app servers.

The problem is the assets on my local machine could differ from the assets the git branch I am deploying from.

Is there a better way or must I just be dillagent to always deploy from the correct clean branch?

Edit here is the cap task that does the precompile and upload

namespace :assets do
  after "deploy:update_code", "assets:precompile"
  after "assets:precompile", "assets:upload_assets"
  after "assets:precompile", "assets:upload_manifest"


  desc "precompile assets"
  task :precompile do
    run_locally("bundle exec rake assets:clean && bundle exec rake assets:precompile RAILS_ENV=#{rails_env}")
  end

  desc "precompile and upload assets to webserver"
    task :upload_assets, :roles => :nginx do
    top.upload( "public/assets", "/usr/local/fieldphone/#{rails_env}/", :via => :scp, :recursive => true)
  end
  # 
  desc "upload manifest file"
  task :upload_manifest, :roles => :app do
    top.upload( "public/manifest.yml", "#{release_path}/public/", :via => :scp )
  end

end
Aaron Renoir
  • 4,283
  • 1
  • 39
  • 61

2 Answers2

0

I don't think there's anything really wrong with committing the files to the repo and deploying that to the Nginx server - that's similar to the vendor cache for gems - it's redundant, but there for a reason.

Another option would be to actually deploy the app to your Nginx servers, and have Capistrano compile the assets there, but not start the app on those servers (create a Capistrano role for "assets" and deploy the app to it, but don't launch it on that role). This could get a bit messy...

As a last option, if you don't want to muddy the waters of your asset servers, or want to keep your options open for deploying assets somewhere else, you could have Capistrano git stash any unsaved changes first, checkout the master branch, and then compile the assets, upload them, remove them, checkout the previous branch (git checkout -), reapply the stashed changes (git stash apply --index), and continue! :)

Resources:

http://git-scm.com/book/en/Git-Tools-Stashing

Is there any way to git checkout previous branch?

Community
  • 1
  • 1
mltsy
  • 6,598
  • 3
  • 38
  • 51
0

You say that assets on your local machines could differ from that on the deploy branch. In normal circumstances your dev environment doesn't need compiled assets.

That being so I'd suggest that you alter your task to remove the assets once they have been deployed, leaving your local working copy clean at all times. This would guarantee that each deploy gets the latest (correct) version of files. (If you are not doing so, I'd also suggest that you use the default options for dev mode which relies on Sprockets to do all the asset serving).

Richard Hulse
  • 10,383
  • 2
  • 33
  • 37
  • The assets might differ because the source sass and coffee files might have recent changes(uncommitted changes, untracked files, etc). I am leaning toward committing the compiled assets(but that feels dirty also). I think it is unnecessary to compile the assets on the production servers and then scp them from the production servers to the correct places(nginx server). – Aaron Renoir Oct 28 '11 at 22:29
  • If there are no compiled files then the assets are all served dynamically. Is that not happening? Also, if you are using the master branch as production/stable then I do not see anything wrong with committing them. – Richard Hulse Oct 28 '11 at 23:07
  • in development yes they are served dynamically. in production they are not served dynamically nginx serves the precompiled files. I would just like to come up with a better way to precompile them and upload them to the nginx server. – Aaron Renoir Oct 29 '11 at 18:39