Какие особенности Liquibase по сравнению с git?
Что проверяют
Понимаете ли вы, что это не конкуренты: Git хранит версии файлов, а Liquibase знает, какие изменения уже применены к конкретной базе. Следом обычно спрашивают, почему нельзя просто держать schema.sql в репозитории и что будет, если отредактировать уже применённый changeset.
Как отвечать
Начните с того, что именно версионируется:
- Git: история текстовых файлов. Он не знает, в каком состоянии сейчас таблицы на проде, на стейдже и у коллеги;
- Liquibase: применяет изменения схемы и ведёт журнал в самой базе, в таблице
DATABASECHANGELOG. Одновременный запуск двух экземпляров блокируется черезDATABASECHANGELOGLOCK.
Дальше устройство. Changelog пишется на XML, YAML, JSON или в размеченном SQL и состоит из наборов изменений (changeset), каждый определяется id, author и путём к файлу. Для каждого применённого набора хранится контрольная сумма, и если файл поменяли задним числом, следующий update остановится с ошибкой проверки. Есть preconditions, контексты и метки для применения части изменений только в нужной среде, а update-sql показывает SQL до запуска.
Откат тоже устроен иначе. git revert возвращает файл, но не данные: удалённая колонка из базы не вернётся. Liquibase умеет автоматический rollback для части операций вроде createTable или addColumn, а для сырого SQL и dropColumn откат описывают сами.
В связке changelog лежит в Git рядом с кодом и проходит ревью, а CI вызывает Liquibase для нужной базы. В data-задачах это схемы хранилища, служебные таблицы пайплайнов и витрины, где окружения не должны расходиться.
Где спотыкаются
Отвечают так, будто нужно выбрать одно из двух. Инструменты работают вместе, и вопрос проверяет именно это.
Правят уже применённый changeset. Правильно добавить новый, а clearCheckSums и runOnChange не способ замести следы, у них своя узкая область.
Забывают про большие таблицы. Changeset с ALTER TABLE по многомиллионной таблице может надолго взять блокировку, Liquibase от этого не защищает, и такие изменения планируют отдельно.