Настройка CI/CD скриптов миграции БД с нуля с использованием GitLab и Liquibase

[SLASH_CyberPunk]

А как вы, при такой структуре liquibase и схеме ci/cd, планируете решать конфликты совместной разработки?

[Doomer3D]

Какого рода конфликты вы имеете в виду?

Если выбрать поход с includeAll, конфликтов не будет, потому что задача разработчиков баз данных будет сводиться к добавлению файлов чейнжсетов.

Впрочем, даже с использованием include и правкой общего файла, конфликты вполне решаются через интерфейс гитлаба, потому что каждый разработчик добавляет свой скрипт в конец файла-аккумулятора.

[SLASH_CyberPunk]

При includeAll вы надеетесь на последовательность, которая задается сортировкой встроенного механизма вывода папок/файлов, там есть первая проблема.
Если у вас разработчик1 пишет миграцию 158 в своей ветке, разработчик2 пишет миграцию тоже 158 в своей ветке, то когда будут мерджи, будут ошибки, которые легко не решить в веб-интерфейсе, и это я еще не зацепил момент, когда объекты этих двух разрабов пересекаются…
З.Ы. ну и главный момент, как вы будете контролировать корректный и последовательный деплой миграций между дев и прод, например?

[Doomer3D]

1. Оба разработчика создают разные файлы, поскольку решают разные задачи. Следовательно, их пути не пересекаются. Об этом написано в статье, в разделе Liquibase.
2. Если у разработчиков пересекаются объекты, то это ненормальная ситуация, которая скорее всего говорит о неправильной постановке задач. Если же это задачи вида «добавить в таблицу T колонку A» для первого разработчика и «добавить в таблицу T колонку B» для второго, то оба изменения пройдут успешно. Это не конфликт.
3. Деплой на прод сводится к формированию релиза, т.е., упрощенно, к мержу из дева в прод. Скрипты подтягиваются и накатываются в том же порядке, что и на деве. Это зона ответственности Liquibase.

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

[Cyapa]

Благодарю за статью. Было интересно прочесть, но, к моему сожалению, самый важный момент, поиски ответа на который и привели меня сюда, остался за кадром. И вопрос этот - откат миграций.

Вот настроили мы пайплайн, выкатываем новый релиз, проходят миграции и тут что-то ломается. Пайплайн падает, релиз не случается, но вот миграции в базе уже есть. Что делать в этом случае? Писать отдельный джоб, который будет запускаться если миграции прошли, а пайплайн нет? Но как узнать какие именно изменения откатывать? Вопрос усложняется наличием пост миграций (в которых обычно делают деструктивные изменения за прошлые релизы).