Comments 13
Николая с днем рождения! красавец!:))))))
Т.е. я как локальный разработчик у себя в "тонкой БД" через dbeaver меняю структуру базы (добавляю/удаляю столбцы, переписываю процедуры и функции и т.п.), а мигратор потом (когда, в какой момент? перед пушем?) соберёт изменения и сгенерит скрипт на изменения, который уже будет запускаться?
И я так и не понял, чего именно не хватило в liquibase/flyway. Пока выглядит это как фатальный недостаток?
Приветствую! Тонкая БД - это для удобства разработки, чтобы "плечами не толкаться". По сути анализ изменений в БД идет по гиту, т.е. условно говоря "от коммита X" до текущего состояния файлов объектов на диске - между ними идет сравнение и генерирование файла скрипта миграции. Потом уже все это (и измененные объекты и сам файл скрипта миграции) коммитится и "точка X передвигается".
Как при этом релизятся миграции БД от разных задач из разных веток?
Если у нас параллельно идёт разработка в develop и исправление ошибок в релизной ветке, то может получиться такая ситуация, что мы создали в develop и в release по одному (для простоты) скрипту кумулятивной миграции. С этого момента на dev стенде и на (пусть это будет тест) тестовом история разъедется. Но нас больше интересует не стройность истории скриптов, а то, что объекты на обоих стендах должны быть идентичны. А для этого мы должны, после мержа релиза в develop , создать 2 скрипта: первый, который принесёт исправления из релизной ветки, а второй должен добавить функциональность, разработанную в develop , пока стабилизировали релиз.
Дальше нужно обеспечить такую схему, которая понимала бы ветвления. Это можно сделать, если у нас файл списка миграций содержит по каждой миграции идентификатор(имя файла) самой миграции и 1или 2 идентификатора предыдущих миграций.
Дальше всё я думаю не сложно. Зная текущую и список предыдущих миграций мы можем спокойно "путешествовать" По ним и можем выяснить непрерывная история или нет.
Добрый день! Ранее пользовались MS SQL и там есть такой инструмент, как sql package, который позволяет также поддерживать структуру базы в SQL скриптах и накатывать миграции сверяя целевую структуру скриптов и текущую базу. При переходе на PostgreSQL искали подобный инструмент и для него, наткнулись на tusker (https://github.com/bikeshedder/tusker), он достаточно сырой, потребовал допила под собственные нужды, но всё же позволяет также поддерживать структуру - при деплое создает чистую копию целевой базы, и между целевой и текущей базой уже проводит сравнение структуры и формирует скрипт миграции (изменения текущий базы), который уже накатывается. Это позволяет привести к нужному виду базу практически любой версии. Насколько я понимаю, у вас сравнения проводятся чисто между скриптами в разных коммитах, что думаете насчет описанного выше подхода?
"от коммита X" до текущего состояния файлов объектов на диске - между ними идет сравнение и генерирование файла скрипта миграции
Так а кто и когда это генерирование запускает? Каким образом определяется этот самый коммит X.
Как говорил один небезызвестный товарищ.
Talk is cheap. Show me the code.
А можно где-то глянуть как оно в живую выглядит?
В миграторе есть 2 варианта: первый установка по задачам. В этом случае генерацией скрипта должен озаботиться сам разработчик задачи, либо всегда можно это перевалить на пайплайны (например в GitLab). Это уже дело вкуса и того как настроены процессы организационно. Но в позадачном режиме запускать создание скрипта нужно локально и обязательно до слияния с develop (иначе как понять что же изменилось).
Второй вариант описан выше и здесь запуск должен производиться специально выделенным человеком в момент, когда есть потребность в установке на тест (например кончился спринт)
Спасибо что поделились вашим опытом. Вижу что в планах у вас есть тесты, а без них я бы не рискнул использовать подобный инструмент.
Применение изменений и запуск юнит-тестов должны выполняться в одной большой транзакции. Если хоть один тест упал, то роллбэк и до свидания.
Каким образом обрабатываются ошибки внесений изменений на Prod базы?
Сценарий:
1. изменяется таблица tblX - добавляется уникальный индекс tblX_IndexZ
2. тестирую в feature ветке (на малых данных) - все ок
3. коммичу в Dev, авто-тест в Dev ветке (на других данных) - все ок
4. релиз, накатываю на Prod (4 базы) - 2 базы - ок, 2 базы - error (unique index violation)
После создания на tblX_IndexZ, разработчики уже напилили новый функционал, с привязкой к tblX_IndexZ.
Как быть, что делать?
Самый простой пример и то, что нам не понравилось в миграциях Liqubase (далее LB) это когда одна функция правится двумя разработчиками. LB при этом предлагает сделать каждому из них свою миграцию и, конечно, каждый положит в миграцию свой код функции. Что будет дальше? Дальше останется вариант того, что сольет свой Merge Request (далее MR) последним
Это в Liquibase решается предельно просто, работал на практике с этим подходом: надо всего лишь задать чёткие правила наименования YAML с чейнджсетами и/или структуру значений ключа id внутри этих чейнджсетов.
Например, разрабы X и Y делают параллельно два разных варианта апдейта функции func() с версии 1.0 на версию 1.1. Они оба должны сделать чейнджсеты с названием файла и id, например, "func()_1.1".
Допустим, разраб X первым закоммитил свою версию. Тогда разраб Y, во-первых, получит merge conflict, а во-вторых, автотесты не пропустят накат двух чейнджсетов Liquibase с одинаковым хэшем id
Контроль корректности наименований файлов в коммитах тоже можно автоматизировать
pgmig — история разработки инструмента управления изменениями в БД или чего нам не хватило в Liquibase и Flyway