Миграции (Flyway)

Миграция — файл, описывающий одно изменение структуры базы (создать таблицу, добавить столбец) — версионируется в Git вместе с кодом, как обычные .java-файлы.

src/main/resources/db/migration/
├── V1__create_users_table.sql
├── V2__add_email_to_users.sql
└── V3__create_orders_table.sql

-- V2__add_email_to_users.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255);

Flyway при запуске приложения сам проверяет, какие миграции уже применены (хранит это в служебной таблице flyway_schema_history), и применяет только новые — по порядку номеров.

Копнуть глубже

Зачем миграции, если можно менять таблицы вручную через консоль. Ручные изменения не версионируются, не повторяемы и не синхронизированы между средами (локально, тест, прод) — структура базы быстро расходится в разных местах, и непонятно, что применено, а что нет. Миграции решают это: история изменений базы лежит в Git рядом с кодом, который её использует, и применяется автоматически и одинаково на любой среде.

Главное правило миграций — никогда не редактировать уже применённую миграцию. Если V2 уже накатили на прод, изменение этого файла не пересоберёт прод-базу заново — там уже всё применено. Нужно создавать новую миграцию (V3) с исправлением, а не трогать историю.

Откат (rollback) в Flyway по умолчанию не поддерживается бесплатно (платная фича Flyway Teams) — обычная практика: пишут новую миграцию, которая отменяет предыдущую, а не “откатывают” старую.

🎤 Закрыл тему, если можешь объяснить:

• зачем нужны миграции вместо ручного изменения таблиц;
• почему нельзя редактировать уже применённую миграцию (если дошёл до 2-го слоя).