On Feb 11, 2008, at 9:05 AM, Gregory Seidman wrote:

On Mon, Feb 11, 2008 at 08:37:11AM -0700, Jamis Buck wrote:
On Feb 11, 2008, at 8:01 AM, Gregory Seidman wrote:

On a related note, what support is there for rolling back not just a
deploy
but migrations as well? Let's call the currently deployed version A and
the
older version we're rolling back to B. If I want to rollback to B I need
to
figure out what migration version B wants, migrate the DB to that version before changing the symlink to point to B, then change the symlink. Is
that
supported?

There is no built-in support for rolling back a migration, because not every migration is reversible, and the only general solution would be to do
a backup of your database before running the migration.

You're pretty much on your own if you want to be able to rollback to a
pre-migration version of your app.

Well, I think that functionality will make some people here more
comfortable/happier, so I'll go about implementing it. When I get it
working I'll post it here. I'll presumably be using a before hook for
deploy:rollback, or even overriding deploy:rollback. I need the path (like current_path) for the version I'm rolling back to, though, and I'm not sure
how to get that. Is it already set somewhere?

You can get that path via the previous_release variable. You can see it in action if you look at the implementation of the rollback_code task.

- Jamis

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to