Как правильно реализовать continuous deployment для запуска миграций?
У нас обычный интернет магазин.
Работаем через git (репа на gitlab).
Сейчас при разработке новых фич, мы вручную заходим на сервер магазина, и делаем git pull с новой фичей.
Часто бывает так, что вместе с кодовой базой, необходимо запустить какой-то скрипт миграции, (или иной скрипт) в рамках текущей, новой фичи.
Сейчас, в корне проекта, у нас есть директория, где размещаются файлы миграций.
Какая миграция, к какой фиче относится, мы понимаем сами.
И после деплоя кода на продакшен, мы вручную запускаем скрипт миграции, который относится к новой фиче.
Подскажите пожалуйста, каким образом это можно автоматизировать через continuous deployment (например через gitlab) ?
А самое главное, непонятно, где и каким образом хранить файлы миграции, чтобы при автоматическом развертывании можно было определить, если у текущей фичи свои файлы миграции или другие скрипты, необходимые для запуска ?
Ну вообще-то все скрипты миграций используют таблицу в БД. В которую пишутся все миграции, которые уже накатились. А сами миграции хранить просто в папке, и накатывать те, которых ещё нет в таблице
Роман Юрьевич Ипатьев, я писал, что не только миграции могут быть, но и любые другие служебные скрипты, которые необходимо запустить после деплоя определенной фичи.
Ну все руками делается.
Делаете каталог для файлов миграции и в нем какой-то главный типа control.sh
в control.sh инклюдите актуальные файлы миграции
Для дедупликации проще всего в базе сделать таблицу, в которую при миграции добавляется "дата, имя скрипта миграции, статус (completed/failed), и при выполнении скрипта миграции соответствнено он проверяет по базе выполнялся уже или нет, чтобы не запускаться вторично. Может быть какие-то скрипты наоборот нужно прогонять каждый раз, тогда можно в таблицу добавить колонку для такого флага.
И все. При автодеплое конкретной версии - в ее ветке оно найдет в control.sh список миграционных скриптов, control.sh через базу данных может перепровить надо ли их запускать или пропустить, если они уже выполнились, или выполнить независимо от этого и сделает запись в базу о выполнении.
Естественно контроль - ответственность разработчиков, магии тут не будет. И предполагается, что вы всегда деплоите более позднюю версию поверх старой.
Простой
Средний
