Какие best practices существуют при работе с Liquibase?

Best practices Liquibase — это набор проверенных правил, которые предотвращают типичные проблемы с миграциями в командной разработке и на продакшене.

1. Один changeset — одно изменение

Каждый changeset должен содержать одно логическое изменение. Это упрощает rollback и отладку.

<!-- Плохо: два изменения в одном changeset -->
<changeSet id="bad-1" author="dev">
    <createTable tableName="orders">...</createTable>
    <createTable tableName="order_items">...</createTable>
</changeSet>

<!-- Хорошо: каждое изменение в отдельном changeset -->
<changeSet id="1" author="dev">
    <createTable tableName="orders">...</createTable>
</changeSet>
<changeSet id="2" author="dev">
    <createTable tableName="order_items">...</createTable>
</changeSet>

2. Никогда не изменять уже применённые changeset-ы

После того как changeset выполнен на любом окружении — его содержимое нельзя менять. Это приведёт к ошибке checksum. Если нужно исправление — создавайте новый changeset.

3. Всегда указывать rollback

Даже если Liquibase может сгенерировать rollback автоматически, явное указание повышает предсказуемость.

4. Именование файлов

Использовать последовательную и понятную схему именования:

db/changelog/
├── db.changelog-master.xml
├── changes/
│   ├── 001-create-users-table.xml
│   ├── 002-create-accounts-table.xml
│   ├── 003-add-email-to-users.xml
│   └── 004-create-transactions-table.xml

5. Использовать осмысленные id

<!-- Плохо -->
<changeSet id="1" author="dev">

<!-- Хорошо -->
<changeSet id="2025-01-15-create-users-table" author="ivanov">

6. Не использовать runAlways и runOnChange без необходимости

Эти атрибуты допустимы для хранимых процедур или представлений, но не для DDL-операций.

7. Использовать logicalFilePath

При переносе файлов changelog в другую директорию указывайте logicalFilePath, чтобы не нарушить уникальность changeset:

<databaseChangeLog logicalFilePath="db/changelog/initial.xml">

8. Тестировать миграции

Использовать updateTestingRollback для проверки, что rollback работает корректно. Запускать миграции на чистой БД в CI.

9. Разделять структурные и data-миграции

Структурные изменения (DDL) и загрузку данных (DML) лучше разделять в разные changeset-ы.

10. Использовать preconditions для безопасности

Особенно полезно при работе с уже существующими БД или при деплое на разные окружения.

На собеседовании: не нужно перечислять все 10 пунктов. Достаточно уверенно назвать три главных: один changeset = одно изменение, не менять применённые changeset-ы, всегда писать rollback. Частая ошибка — не упомянуть правило неизменяемости changeset-ов.