Как организовать откат миграций БД при откате к предыдущему релизу?

Многие используют для деплоя специальный софт: Capistrano, Deployer и т.д. Я не исключение, использую Deployer, хотя в данном случае это не важно. Софт - php, Laravel, mysql, но это тоже не особо важно, я хочу понять принцип.

Такой софт использует "релизы", т.е. каждый раз, когда я выполняю команду deploy, на сервере создается новый каталог, куда заливается последняя версия кода из репозитория и где выполняются миграции (php artisan migrate).

Также можно сделать откат релиза, когда последний релиз просто удаляется с сервера и используется предпоследний.

Вопрос в том, как в эту схему вписать откат миграций БД? Вообще, нет никаких препятствий — бери и выполняй artisan migrate:rollback при вызове deployer rollback. Но есть проблема — если в последнем релизе не было миграций вообще. Тогда откат к предпоследнему релизу откатит миграции, которые сейчас не надо откатывать, ведь скрипт роллбэка довольно тупой, он не знает — когда нужно откатывать миграции, а когда не нужно.

Как вы реально решали эту проблему? На данный момент я откатываю миграции только вручную. К счастью, операция отката нужна редко. Чисто теоретически, можно в папку с каждым релизом класть файл-флаг (например, releaseHasMigration). И при откате релиза проверять: если файл существует, нужно сделать откат. Если нет — не делать. Но как реализовать такое решение на уровне Deployer'а я не знаю.

Поэтому и задаю тут вопрос. Может быть есть другие решения?
  • Вопрос задан
  • 1113 просмотров
Решения вопроса 1
@LiguidCool
По моему откат это далеко не ежедневная операция и при необходимости должна выполняться ручками. Лучше тщательнее тестировать релиз ...
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы