On Jul 14, 2010, at 12:00 AM, Lawrence Pit wrote: > It appears unicorn rolls back by itself when it can't start the new master. > Nice! > > Jamie also mentions to use the shared vendor/bundler_gems path. Though I do > use that in all my projects I'm not so sure it's wise to do when you can't > afford any downtime. I'll have to wait for unicorn v1.1.3 before I can test > whether rolling back will indeed continue with unicorn v1.1.2 instead of > v1.1.3 ;o
Hi Lawrence, why does the shared vendor/bundler_gems cause you downtime? From not re-bundling during rollback? FWIW I made that recommendation because I ran into issues with unicorns not restarting correctly after running `cap deploy:cleanup`, since the `bundle exec` launches a binary with a path like /app/releases/201007125236/bin/unicorn, which goes missing after N deploys. I haven't tested if this applies to more recent versions Shared bundles are also significantly faster -- `bundle check || bundle install` is ~1s for me vs. several minutes to totally rebundle -jamie http://jamiedubs.com http://fffff.at _______________________________________________ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
