Как правильно реализовать continuous deployment для запуска миграций?

У нас обычный интернет магазин.
Работаем через git (репа на gitlab).

Сейчас при разработке новых фич, мы вручную заходим на сервер магазина, и делаем git pull с новой фичей.

Часто бывает так, что вместе с кодовой базой, необходимо запустить какой-то скрипт миграции, (или иной скрипт) в рамках текущей, новой фичи.

Сейчас, в корне проекта, у нас есть директория, где размещаются файлы миграций.
Какая миграция, к какой фиче относится, мы понимаем сами.
И после деплоя кода на продакшен, мы вручную запускаем скрипт миграции, который относится к новой фиче.

Подскажите пожалуйста, каким образом это можно автоматизировать через continuous deployment (например через gitlab) ?

А самое главное, непонятно, где и каким образом хранить файлы миграции, чтобы при автоматическом развертывании можно было определить, если у текущей фичи свои файлы миграции или другие скрипты, необходимые для запуска ?
  • Вопрос задан
  • 281 просмотр
Пригласить эксперта
Ответы на вопрос 4
saboteur_kiev
@saboteur_kiev Куратор тега bash
software engineer
Ну все руками делается.
Делаете каталог для файлов миграции и в нем какой-то главный типа control.sh
в control.sh инклюдите актуальные файлы миграции
Для дедупликации проще всего в базе сделать таблицу, в которую при миграции добавляется "дата, имя скрипта миграции, статус (completed/failed), и при выполнении скрипта миграции соответствнено он проверяет по базе выполнялся уже или нет, чтобы не запускаться вторично. Может быть какие-то скрипты наоборот нужно прогонять каждый раз, тогда можно в таблицу добавить колонку для такого флага.

И все. При автодеплое конкретной версии - в ее ветке оно найдет в control.sh список миграционных скриптов, control.sh через базу данных может перепровить надо ли их запускать или пропустить, если они уже выполнились, или выполнить независимо от этого и сделает запись в базу о выполнении.

Естественно контроль - ответственность разработчиков, магии тут не будет. И предполагается, что вы всегда деплоите более позднюю версию поверх старой.
Ответ написан
Комментировать
BorLaze
@BorLaze
Java developer
Не изобретайте велосипед.

Есть готовый инструмент для миграций Flyway - проще некуда.
Ответ написан
@vitaly_il1
DevOps Consulting
Согласен с BorLaze - используйте что-то готовое. Например https://www.liquibase.org/.
Ответ написан
Комментировать
правильно реализовать continuous deployment для запуска миграций
через предварительное резервное копирование. Всяко бывало
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы