Как осуществляется версионирование базы данных и какие инструменты используются (Liquibase, Flyway и другие)

Что проверяют

Работали ли вы с миграциями на живом проекте, а не только в учебном. Следом обычно спрашивают, что будет, если поправить уже применённую миграцию, и как выкатить изменение схемы без простоя.

Как отвечать

Суть у всех инструментов одна: схема меняется только скриптами миграций, которые лежат в репозитории рядом с кодом, а в базе ведётся таблица истории с тем, что уже применено.

• Flyway: файлы V1__init.sql, V2__add_status.sql в db/migration, история в flyway_schema_history с контрольными суммами. Есть повторяемые R__ для представлений и функций. Undo-миграций в бесплатной редакции нет;
• Liquibase: changelog в XML, YAML, JSON или SQL, каждый changeSet опознаётся по id, автору и файлу. История в DATABASECHANGELOG, блокировка в DATABASECHANGELOGLOCK. Есть блоки rollback, preConditions, контексты и метки для разных окружений;
• Spring Boot: оба подхватываются автоконфигурацией при старте, настройки в spring.flyway.* и spring.liquibase.*. Если стартуют несколько инстансов, миграцию выполняет один, остальные ждут блокировку.

Как выбирать: Flyway проще, когда команда пишет обычный SQL под одну СУБД. Liquibase удобнее при нескольких СУБД и когда нужны откаты и условия выполнения.

Про выкатку без простоя расскажите схему expand/contract: добавить новую колонку и научить код писать в обе, перенести данные пачками и только следующим релизом удалить старое. Если сразу переименовать колонку, при rolling-деплое старые инстансы упадут на новой схеме. CREATE INDEX CONCURRENTLY в PostgreSQL не работает внутри транзакции, такую миграцию явно помечают нетранзакционной.

Где спотыкаются

Редактируют уже применённую миграцию. Контрольная сумма расходится, validate падает, а там, где старая версия уже прошла, изменения не будет. Правка всегда оформляется новой миграцией.

Держат spring.jpa.hibernate.ddl-auto=update вместе с миграциями. Hibernate меняет схему в обход истории, и базы на разных стендах расходятся.

Обещают откатить любую миграцию. Откат удалённой колонки не вернёт данные, поэтому на проде обычно катят исправление вперёд, а не назад.