 |
From: Donovan Bray <donno...@gmail.com>
Date: Mon, 1 Oct 2012 19:50:01 -0700
Local: Mon, Oct 1 2012 10:50 pm
Subject: Re: [capistrano] shared bundle versioning
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/t...
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 <ethan.wa...@gmail.com> 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 capistrano@googlegroups.com > * To unsubscribe from this group, send email to capistrano+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||