Even before bundler came with cap tasks built In I anticipated this problem. I use my own bundler recipes https://github.com/donnoman/cap-recipes/blob/master/lib/cap_recipes/tasks/bundler/install.rb
It creates a bundled directory in shared but it's not symlinked. Instead it's used like a cache to seed a new release directory; where bundler is ultimately run. A succesful deploy copies the resulting bundle back to shared to be used for the next deploy. Because each release ends up with its own bundle a rollback works exactly as expected since its the same bundle that was deployed for THAT revision of code. Because the bundle doesn't need to be recalculated rollback is fast. The downside is a mature code base will have a big bundle and you have to tune how many release directories you want to keep. On Oct 1, 2012, at 1:02 PM, Ethan Waldo <[email protected]> wrote: > We recently came across a situation where we couldn't rollback a deployment > because the new deployment borked the gems in the bundler gem cache. > Capistrano does a great job of versioning the code, but it seems to me that > the bundle of gems should be versioned as well to ensure the rollback will > succeed. > -- > * You received this message because you are subscribed to the Google Groups > "Capistrano" group. > * To post to this group, send email to [email protected] > * To unsubscribe from this group, send email to > [email protected] For more options, visit this group at > http://groups.google.com/group/capistrano?hl=en -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
