Миграции БД с Flyway в Java: безопасность и практическое применение
Салимжанов Р.
Миграции базы данных — важный процесс в разработке, позволяющий управлять изменениями структуры БД. Flyway — популярный инструмент для версионирования и автоматизации миграций.
Он позволяет:
✅ Автоматизировать обновление структуры БД
✅ Контролировать версионность изменений
✅ Обеспечивать безопасность миграций
В этой статье мы разберём:
- Как настроить Flyway в Spring Boot.
- Пример миграции с кодом.
- Почему Flyway безопаснее ручных SQL-скриптов?
1. Настройка Flyway в Spring Boot
1.1. Добавляем зависимость
В pom.xml (Maven):
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>10.20.1</version>
</dependency>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-database-postgresql</artifactId>
<version>10.20.1</version>
</dependency>
1.2. Настройка БД
В application.properties:
В application.properties:
server.port=8082
# DB
spring.datasource.url=jdbc:postgresql://localhost:5432/basetest
spring.datasource.username=postgres
spring.datasource.password=postgres
# Hibernate
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true
# Flyway Configuration
spring.flyway.enabled=true
spring.flyway.baseline-on-migrate=true
spring.flyway.locations=classpath:db/migration
logging.level.org.flywaydb=DEBUG
logging.level.org.springframework.jdbc=DEBUG
1.3. Конфигурация Flyway
Класс FlywayConfig настраивает Flyway для работы с базой данных:
@Configuration
public class FlywayConfig {
@Bean
public Flyway flyway(DataSource dataSource) {
return Flyway.configure()
.dataSource(dataSource) // Источник данных (БД)
.baselineOnMigrate(true) // Создаёт baseline при первом запуске
.baselineVersion("0") // Начальная версия миграций
.validateOnMigrate(false) // Отключает валидацию (для гибкости)
.outOfOrder(true) // Разрешает применять миграции не по порядку
.load();
}
}
Ключевые параметры:
- baselineOnMigrate — автоматически создаёт базовую версию, если БД новая.
- validateOnMigrate — если false, Flyway пропустит проверку целостности миграций (полезно при разработке).
- outOfOrder — разрешает применять миграции не в порядке версий.
1.4. Запуск миграций
Класс FlywayRunner выполняет миграции и логирует процесс:
@Component
public class FlywayRunner implements CommandLineRunner {
private final Flyway flyway;
public FlywayRunner(Flyway flyway) {
this.flyway = flyway;
}
@Override
public void run(String... args) {
System.out.println("=== Flyway migration start ===");
System.out.println("Flyway version: " + Flyway.class.getPackage().getImplementationVersion());
// Применяем миграции
MigrateResult migrationsApplied = flyway.migrate();
System.out.println("Applied " + migrationsApplied.migrationsExecuted + " migrations");
// Выводим список применённых миграций
System.out.println("=== Applied migrations ===");
for (MigrationInfo info : flyway.info().applied()) {
System.out.println(info.getVersion() + " - " + info.getDescription());
}
}
}
Что делает этот код?
- Запускает миграции (flyway.migrate()).
- Выводит количество применённых изменений.
- Логирует список выполненных миграций.
2. Пример миграции
2.1. Создаём SQL-скрипты
Flyway требует, чтобы миграции лежали в src/main/resources/db/migration/:
Первая миграция (V1__Create_users_table.sql)
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username VARCHAR(50) NOT NULL,
password VARCHAR(100) NOT NULL
);
Вторая миграция (V2__Add_email_column.sql)
ALTER TABLE users ADD COLUMN email VARCHAR(100);
2.2. Запуск приложения
При старте Spring Boot:
- Flyway проверит, есть ли таблица flyway_schema_history.
- Если нет — создаст её.
- Применит все не применённые миграции в порядке версий.
После запуска в БД появится:
- Таблица users (из V1).
- Столбец email (из V2).
- Таблица flyway_schema_history (журнал миграций).
Как видим, до запуска нет таблиц:
После запуска:
3. Безопасность миграций с Flyway
✅ 1. Контроль версий
- Каждый скрипт имеет уникальную версию (V1, V2, ...).
- Flyway не позволяет выполнить одну миграцию дважды (защита от дублирования).
✅ 2. Идемпотентность (безопасность повторного запуска)
- Можно писать SQL так, чтобы миграция не ломалась при повторном запуске:
-- V3__Add_index_username.sql
CREATE INDEX IF NOT EXISTS idx_username ON users(username);
✅ 3. Откат изменений (через откатные миграции)
- Flyway поддерживает откатные миграции (U__...sql):
-- U2__Drop_email_column.sql
ALTER TABLE users DROP COLUMN email;
✅ 4. Защита от человеческих ошибок
Ручные sql скрипты могут:
- Забыть применить.
- Запустить в неправильном порядке.
- Сломать БД из-за опечатки.
Flyway гарантирует:
- Все миграции выполняются последовательно.
- Нельзя пропустить миграцию.
- Легко отследить историю изменений.
✅ 5. Интеграция с CI/CD
- Flyway можно встроить в автоматические пайплайны (GitHub Actions, Jenkins).
- Перед деплоем можно тестировать миграции на staging-БД.
Когда использовать Flyway?
- В проектах с частыми изменениями структуры БД.
- Для командной разработки (чтобы у всех была одинаковая схема БД).
- Если важна безопасность и предсказуемость миграций.
Начать дискуссию