On Thu, Jan 14, 2010 at 22:04, Scott Olmsted <[email protected]> wrote:

> Do you do anything, maybe with Git, to be ready to roll back and sync the
> last known working version of the code?
>

Git and cap really do work well for this scenario. I've had some projects
that I've set up to deploy using git along similar lines to what GitHub
does, based on their blog post of a few months back:
http://github.com/blog/470-deployment-script-spring-cleaning

If you're already using git, I highly recommend giving that setup a try.

GitHub's approach to rollbacks in that blog post is to simply roll back one
commit at a time. Which works if you deploy frequently (and congrats if you
are!). If not, it's still relatively straightforward to add the kind of
rollback support you need.

Just apply some kind of timestamp-based tag to the repository when you
perform the deploy. On a rollback, you can list and sort these tags, remove
the latest one, check out the previous, and re-run the deploy action. In
fact, Capistrano uses a couple variables (releases, current_release, and
previous_release) set to lambdas that load and manage just this sort of
thing.

Something like this should get you started down that road, once you've got a
GitHub-eque deploy.rb in place…

set :releases, lambda { capture("cd #{current_path} && git tag -l
> 'deploy-*'").split.reverse }


> namespace :deploy do

  namespace :rollback do

    task :default do

      # set branch to previous_release (you may need to give that its own
> lambda, too)

      # remove the current_release tag remotely

      # re-run deploy.default

    end

  end

end


Someone else may have a better/easier/rsync-ier way of doing this, but
that's what has worked for me.

Putting down my hammer and taking another look at your particular nail…
would simply checking out the working version locally, then rsyncing, not
accomplish what you need here? Either way, I don't imagine it's particularly
graceful in the event of a failed deploy, and all the lovely adrenaline that
comes with it… ;-)

Let us know how it goes.

-- 
Nick Zadrozny
-- 
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby

Reply via email to