Deploy with Capistrano

[mattiassvedhem]

So I'm easily able to go up with the migrations on Capistrano deploy.
I would like to implement going down on Capistrano rollback, how would you go about that?

Something like this, or is there any easier way?

On deploy, read from the db and save the belonging db version number in a file in the deployed directory.
Then on rollback, read from the file and take the db back to the right version.

[andreascreten]

Sounds like the easiest way to do it indeed.

[ruckus]

When you say rollback do you mean that if during a deploy, the migrations complete but then the deploy fails after that, so you want to rollback any DB changes?

[ghost]

yes, but also there is another case where the deploy succeeds, but you then want to roll it back anyway. In that case, you need to read the version from the schema.txt file of the OLD deploy. It is not currently written to the schema.txt so this would not be possible.

[salimane]

is this issue still valid ? if you want to rollback, you can do php ruckus.php db:migrate VERSION=-1 . Or may be I'm misunderstanding something
Thanks

[RichardBradley]

@salimane -- db:migrate VERSION=-1 isn't sufficient, as there is no guarantee that each Capistrano deploy added only one new migration to the live database. The feature request here seems to be for Capistrano to remember the schema version of each deploy, so that Capistrano "rollbacks" can integrate with ruckus.

[RichardBradley]

One way to implement this might be to add a new ruckus command which rolls back any migrations which are found in the schema_migrations table, but which do not have corresponding migrations in the codebase.
Say ruckus.php db:rollback_to_codebase

Then, in capistrano, after reverting the current link to the old codebase dir, you would cd into that version of the code and run the new rollback command.

( "you need to read the version from the schema.txt file of the OLD deploy" -- this approach would work in projects where the DB history is completely linear, but not on projects which have branches + merges. The version number is not sufficient to uniquely identify a DB version in those cases. )