Liquibase: Гайд по безболезненным миграциям баз данных
На сегодняшний день поддержка целостности баз данных и управление миграциями схем и данных — важная часть процесса разработки. Одним из популярных и гибких инструментов для управления изменениями БД является Liquibase. Liquibase — это open-source решение, которое позволяет:
- Хранить историю изменений в виде версионированных файлов
- Откатывать изменения при необходимости
- Применять миграции в любой среде
- Работать с разными СУБД
Как лучше определять миграции
Liquibase работает с changelog-файлами, которые описывают изменения в декларативном виде. Вот некоторые рекомендации по формированию changelog-файлов:
✔ Использовать XML/YAML/JSON формат
Хотя Liquibase и поддерживает формат SQL, предпочтительнее использовать декларативные форматы — JSON/XML/YAML. В этом варианте использования мы получим все преимущества, которые может предоставить Liquibase:
- Кроссплатформенность: один и тот же changelog работает на разных СУБД (PostgreSQL, MySQL, Oracle и др.).
- Контроль изменений: изменения описываются структурированно, их легче анализировать.
- Дополнительные преимущества: можно использовать preConditions, rollback, валидацию.
Хотя и у подхода, когда мы определяем миграции в SQL-файлах, есть свои преимущества:
- Гибкость — можно использовать специфичные особенности для СУБД, которые Liquibase не поддерживает в декларативном виде.
- Читаемость — SQL понятен любому DBA или разработчику без изучения Liquibase-синтаксиса.
✔ Соблюдать режим атомарности
Каждая миграция должна делать одну логическую вещь - например, создание таблицы или добавление/изменение колонки. Пример changeset'а:
Для крупных проектов удобно хранить миграции в отдельных файлах, а потом подключать их в главном changelog.xml.
✔ Добавлять комментарии и версионировать файлы
Лучше всего группировать изменения по версиям продукта — v0, v1. При использовании Liquibase в модульном монолите стоит разделять миграции по модулям.
✔ Использовать id и author для уникальности
Каждый changeset должен иметь уникальный id и author. Это необходимо для отслеживания изменений и разрешения конфликтов.
Запуск миграций
Существует два основных подхода: запуск при старте приложения и запуск отдельным шагом пайплайна CI/CD. В последнее время большинство разработчиков склоняется к запуску миграций через Maven/Gradle в CI/CD, в этом случае мы получаем дополнительные преимущества:
✅ Более контролируемо – миграции выполняются до деплоя приложения.
✅ Меньше рисков – если миграция упадет, приложение не запустится с несовместимой схемой.
✅ Лучше для кластера – нет риска гонки, в кластере несколько инстансов могут пытаться применить миграции одновременно.
Некоторые уникальные возможности liquibase
Генерация changelog из существующей БД:
liquibase generateChangeLog — полезно при переходе на Liquibase.
Context и labels:
Можно применять миграции в нужных средах и при определенных параметрах, которые будут передаваться при запуске (можно использовать, например, для заполнения тестовых данных):
Предикаты (preConditions):
Можно проверить условия перед выполнением миграций:
Шаблоны (customChange):
Если очень нужно, можно реализовать собственные Java-классы для сложных миграций.
SQL output:
Можно сгенерировать SQL-файл без применения: liquibase updateSQL
Генерация документации:
Можно создать документацию в формате JavaDoc для changeset и БД с помощью db-doc
Liquibase экономит время и снижает риски при миграции БД. При использовании XML и настраивании автоматизации через CI/CD можно значительно повысить гибкость в управлении миграциями БД.
А кто-нибудь хоть раз использовал rollback-механизм Liquibase в проде, в моем опыте такого ни разу не видел?
Мой канал в telegram