Comments 5
А как вы, при такой структуре liquibase и схеме ci/cd, планируете решать конфликты совместной разработки?
Какого рода конфликты вы имеете в виду?
Если выбрать поход с includeAll, конфликтов не будет, потому что задача разработчиков баз данных будет сводиться к добавлению файлов чейнжсетов.
Впрочем, даже с использованием include и правкой общего файла, конфликты вполне решаются через интерфейс гитлаба, потому что каждый разработчик добавляет свой скрипт в конец файла-аккумулятора.
Если выбрать поход с includeAll, конфликтов не будет, потому что задача разработчиков баз данных будет сводиться к добавлению файлов чейнжсетов.
Впрочем, даже с использованием include и правкой общего файла, конфликты вполне решаются через интерфейс гитлаба, потому что каждый разработчик добавляет свой скрипт в конец файла-аккумулятора.
При includeAll вы надеетесь на последовательность, которая задается сортировкой встроенного механизма вывода папок/файлов, там есть первая проблема.
Если у вас разработчик1 пишет миграцию 158 в своей ветке, разработчик2 пишет миграцию тоже 158 в своей ветке, то когда будут мерджи, будут ошибки, которые легко не решить в веб-интерфейсе, и это я еще не зацепил момент, когда объекты этих двух разрабов пересекаются…
З.Ы. ну и главный момент, как вы будете контролировать корректный и последовательный деплой миграций между дев и прод, например?
Если у вас разработчик1 пишет миграцию 158 в своей ветке, разработчик2 пишет миграцию тоже 158 в своей ветке, то когда будут мерджи, будут ошибки, которые легко не решить в веб-интерфейсе, и это я еще не зацепил момент, когда объекты этих двух разрабов пересекаются…
З.Ы. ну и главный момент, как вы будете контролировать корректный и последовательный деплой миграций между дев и прод, например?
- Оба разработчика создают разные файлы, поскольку решают разные задачи. Следовательно, их пути не пересекаются. Об этом написано в статье, в разделе Liquibase.
- Если у разработчиков пересекаются объекты, то это ненормальная ситуация, которая скорее всего говорит о неправильной постановке задач. Если же это задачи вида «добавить в таблицу T колонку A» для первого разработчика и «добавить в таблицу T колонку B» для второго, то оба изменения пройдут успешно. Это не конфликт.
- Деплой на прод сводится к формированию релиза, т.е., упрощенно, к мержу из дева в прод. Скрипты подтягиваются и накатываются в том же порядке, что и на деве. Это зона ответственности Liquibase.
По этой схеме разработчики работали уже не первый год, и серьезных проблем не возникало.
Благодарю за статью. Было интересно прочесть, но, к моему сожалению, самый важный момент, поиски ответа на который и привели меня сюда, остался за кадром. И вопрос этот - откат миграций.
Вот настроили мы пайплайн, выкатываем новый релиз, проходят миграции и тут что-то ломается. Пайплайн падает, релиз не случается, но вот миграции в базе уже есть. Что делать в этом случае? Писать отдельный джоб, который будет запускаться если миграции прошли, а пайплайн нет? Но как узнать какие именно изменения откатывать? Вопрос усложняется наличием пост миграций (в которых обычно делают деструктивные изменения за прошлые релизы).
Sign up to leave a comment.
Настройка CI/CD скриптов миграции БД с нуля с использованием GitLab и Liquibase