Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

db:rollback #110

Open
blackjid opened this issue Apr 9, 2015 · 6 comments
Open

db:rollback #110

blackjid opened this issue Apr 9, 2015 · 6 comments

Comments

@blackjid
Copy link

blackjid commented Apr 9, 2015

Hi, I wanted to rollback an application but the database was not rolled back.

What do you think about adding a deploy:db:rollback to this gem. This task could be also hooked after the deploy:reverted hook and run rake db:rollback

@kirs
Copy link
Member

kirs commented Apr 18, 2015

The best practice is usually to keep db schema/migrations capable with previous version of app.
For example if you rename the avatar column to userpic, instead of renaming the column directly, create a new column and then copy the values. After the release, you could remove the older column.

By using this trick, you will make the old-running code capable with the new schema (at the moment when DB is already migrated but app is not restarted yet).

But generally speaking, we could add this task as a optional and mention it in README.

@printercu
Copy link
Contributor

@kirs this is good approach. Though db:rollback can be useful in staging and testing environments.

@stoivo
Copy link

stoivo commented Oct 16, 2017

Add lib/capistrano/tasks/db_rollback.rake

namespace :deploy do
  namespace :db do
    desc 'Rollback db'
      task rake: [:set_rails_env] do
        on release_roles([:db]) do
          within release_path do
            with rails_env: fetch(:rails_env) do
              execute :rake, "db:rollback
            end
          end
        end
      end
  end
end

That file will we autoloaded bu Capfile

# Load custom tasks from `lib/capistrano/tasks` if you have any defined
Dir.glob('lib/capistrano/tasks/*.rake').each { |r| import r }

@Tensho
Copy link

Tensho commented Jan 12, 2018

I agree with @printercu, during development/testing you may write incorrect migration, run it (within cap deploy), get error, re-write migration to make it correct, rollback (it'd be nice to do it within cap task), git push, cap deploy:migrate. It's especially useful for non-translational DDL dbs, like MySQL.
@kirs, is it considerable to add deploy:db:rollback task and rename deploy:migrate to deploy:db:migrate? I didn't read the whole history of capistrano-rails, that's why I'm asking about. Ready to provide PR ^_^

@tomdev
Copy link

tomdev commented Mar 14, 2018

This could get hairy when there are multiple migrations in a single release: rake db:rollback will only rollback the latest migration.

http://edgeguides.rubyonrails.org/active_record_migrations.html#rolling-back

It is also possible that only a few migration succeeded. Unsure what migration rake db:rollback would rollback. Hopefully the latest migration with up state in the schema_migrations table.

Just a few things to take into consideration here.

@printercu
Copy link
Contributor

Unsure what migration rake db:rollback would rollback.

The latest successful.

STEP envvar can be passsed to rake from cap to rollback more migrations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants