🔥 Как настроить Liquibase для управления миграциями БД
Liquibase — это инструмент для версионирования схемы базы данных. Забудьте про ручные SQL-скрипты и проблемы с синхронизацией между окружениями.
Работает декларативно, отслеживает все изменения, поддерживает rollback и работает с любыми реляционными БД.
1️⃣ Добавляем зависимости
Нужна одна основная зависимость: liquibase-core. Если используете Spring Boot, добавьте spring-boot-starter-liquibase — он автоматически интегрируется с DataSource и запускается при старте приложения.
Критически важно добавить JDBC-драйвер вашей БД (postgresql, mysql-connector и т.д.). Без него Liquibase не сможет подключиться и применить миграции.
2️⃣ Создаём структуру changelog-файлов
Создайте директорию resources/db/changelog/. В корне положите главный файл db.changelog-master.yaml — это точка входа, которая включает все остальные миграции.
В мастер-файле перечисляете пути к конкретным changeset-файлам в порядке применения. Называйте файлы по схеме: v1.0-create-users-table.yaml, v1.1-add-email-column.yaml — так проще ориентироваться в истории изменений.
3️⃣ Настраиваем application.yml
В конфигурации укажите путь к мастер-файлу через параметр spring.liquibase.change-log. По умолчанию это classpath:db/changelog/db.changelog-master.yaml.
Обязательно настройте параметры enabled (включить/выключить), drop-first (очистка БД перед стартом — только для dev!) и contexts (для разделения миграций по окружениям: dev, test, prod).
4️⃣ Пишем changeset'ы
Каждое изменение оборачивается в changeset с уникальным id и автором. Liquibase отслеживает, какие changeset'ы уже применены через служебную таблицу databasechangelog.
Основные типы изменений:
▪️ createTable / dropTable — создание/удаление таблиц
▪️ addColumn / dropColumn — добавление/удаление колонок
▪️ createIndex — создание индексов для оптимизации запросов
▪️ addForeignKey — настройка связей между таблицами
▪️ insert / update — заполнение справочников и тестовых данных
▪️ sql / sqlFile — для сложных кастомных запросов
Используйте preconditions для проверки условий перед применением: например, не создавать таблицу, если она уже существует.
5️⃣ Настраиваем rollback
Liquibase умеет откатывать изменения. Для большинства операций rollback генерируется автоматически, но для sql и sqlFile нужно явно указывать rollback-блок.
Добавляйте тег rollback с SQL-командами отката. Для createTable это будет dropTable, для addColumn — dropColumn. Это критически важно для production — без rollback вы не сможете откатить проблемную миграцию.
6️⃣ Работа с разными окружениями
Используйте contexts и labels для разделения миграций. Тестовые данные помечайте context="dev", production-миграции — context="prod". При запуске приложения указывайте нужный context в конфигурации.
Можно создать отдельные файлы для каждого окружения: db.changelog-dev.yaml с тестовыми данными и db.changelog-prod.yaml только со структурными изменениями. Подключайте их условно через профили Spring.
7️⃣ Лучшие практики
▪️ Никогда не изменяйте уже применённые changeset'ы — создавайте новые для исправлений
▪️ Один changeset = одно атомарное изменение. Не пихайте всё в один файл
▪️ Используйте runOnChange="false" чтобы changeset применялся только один раз
▪️ Добавляйте failOnError="true" для критичных миграций
▪️ Тестируйте миграции на копии production БД перед деплоем
✔️ Что происходит под капотом
При старте приложения Liquibase подключается к БД и проверяет наличие служебных таблиц DATABASECHANGELOG и DATABASECHANGELOGLOCK. Если их нет — создаёт.
Затем читает master-файл, получает список всех changeset'ов и сверяет с таблицей DATABASECHANGELOG. Новые changeset'ы применяются последовательно, информация о них записывается в таблицу с MD5-хэшем для контроля целостности.
💡 Бонус-совет
Интегрируйте Liquibase с CI/CD. Перед деплоем запускайте команду liquibase validate для проверки корректности changelog'ов. В pipeline добавьте команду liquibase updateSQL чтобы увидеть, какой SQL будет выполнен, без реального применения.
🐸 Библиотека джависта
#Enterprise
Liquibase — это инструмент для версионирования схемы базы данных. Забудьте про ручные SQL-скрипты и проблемы с синхронизацией между окружениями.
Работает декларативно, отслеживает все изменения, поддерживает rollback и работает с любыми реляционными БД.
Нужна одна основная зависимость: liquibase-core. Если используете Spring Boot, добавьте spring-boot-starter-liquibase — он автоматически интегрируется с DataSource и запускается при старте приложения.
Критически важно добавить JDBC-драйвер вашей БД (postgresql, mysql-connector и т.д.). Без него Liquibase не сможет подключиться и применить миграции.
Создайте директорию resources/db/changelog/. В корне положите главный файл db.changelog-master.yaml — это точка входа, которая включает все остальные миграции.
В мастер-файле перечисляете пути к конкретным changeset-файлам в порядке применения. Называйте файлы по схеме: v1.0-create-users-table.yaml, v1.1-add-email-column.yaml — так проще ориентироваться в истории изменений.
В конфигурации укажите путь к мастер-файлу через параметр spring.liquibase.change-log. По умолчанию это classpath:db/changelog/db.changelog-master.yaml.
Обязательно настройте параметры enabled (включить/выключить), drop-first (очистка БД перед стартом — только для dev!) и contexts (для разделения миграций по окружениям: dev, test, prod).
Каждое изменение оборачивается в changeset с уникальным id и автором. Liquibase отслеживает, какие changeset'ы уже применены через служебную таблицу databasechangelog.
Основные типы изменений:
▪️ createTable / dropTable — создание/удаление таблиц
▪️ addColumn / dropColumn — добавление/удаление колонок
▪️ createIndex — создание индексов для оптимизации запросов
▪️ addForeignKey — настройка связей между таблицами
▪️ insert / update — заполнение справочников и тестовых данных
▪️ sql / sqlFile — для сложных кастомных запросов
Используйте preconditions для проверки условий перед применением: например, не создавать таблицу, если она уже существует.
Liquibase умеет откатывать изменения. Для большинства операций rollback генерируется автоматически, но для sql и sqlFile нужно явно указывать rollback-блок.
Добавляйте тег rollback с SQL-командами отката. Для createTable это будет dropTable, для addColumn — dropColumn. Это критически важно для production — без rollback вы не сможете откатить проблемную миграцию.
Используйте contexts и labels для разделения миграций. Тестовые данные помечайте context="dev", production-миграции — context="prod". При запуске приложения указывайте нужный context в конфигурации.
Можно создать отдельные файлы для каждого окружения: db.changelog-dev.yaml с тестовыми данными и db.changelog-prod.yaml только со структурными изменениями. Подключайте их условно через профили Spring.
▪️ Никогда не изменяйте уже применённые changeset'ы — создавайте новые для исправлений
▪️ Один changeset = одно атомарное изменение. Не пихайте всё в один файл
▪️ Используйте runOnChange="false" чтобы changeset применялся только один раз
▪️ Добавляйте failOnError="true" для критичных миграций
▪️ Тестируйте миграции на копии production БД перед деплоем
При старте приложения Liquibase подключается к БД и проверяет наличие служебных таблиц DATABASECHANGELOG и DATABASECHANGELOGLOCK. Если их нет — создаёт.
Затем читает master-файл, получает список всех changeset'ов и сверяет с таблицей DATABASECHANGELOG. Новые changeset'ы применяются последовательно, информация о них записывается в таблицу с MD5-хэшем для контроля целостности.
Интегрируйте Liquibase с CI/CD. Перед деплоем запускайте команду liquibase validate для проверки корректности changelog'ов. В pipeline добавьте команду liquibase updateSQL чтобы увидеть, какой SQL будет выполнен, без реального применения.
#Enterprise
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤2🔥1
JMH — это фреймворк для точного микробенчмаркинга в Java
Он предназначен для создания тестов производительности, которые помогают анализировать, как различные изменения в коде влияют на его эффективность.
▪️ измерение времени выполнения на уровне микроопераций;
▪️ поддержка сложных случаев оптимизации JVM;
▪️ вывод подробной статистики;
▪️ возможность настройки параметров теста;
▪️ точные результаты без влияния JVM-оптимизаций.
#Enterprise
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2👏1