Что такое Flyway и для чего он используется?

Слушай, а вот есть такая штука — Flyway. Представь себе, что твоя база данных — это квартира, а ты такой, приехал в новостройку, где голые стены и один унитаз посередине зала. И ты начинаешь её обживать: сначала стены, потом розетки, потом мебель заносишь. Так вот, Flyway — это твой личный прораб, который не даст тебе на второй день забыть, куда ты диван поставил, и не позволит рабочим вмазать кондиционер в несущую стену, потому что «так захотелось».

Короче, это инструмент, который контролирует версии и управляет миграциями для базы. Он берёт твои SQL-скрипты (или даже Java-код, если ты совсем извращенец) и применяет их к базе строго по порядку, как инструкцию по сборке шкафа из Икеи, только без лишних деталей и кривых рук.

Суть, если по-простому:

• Миграция — это файлик, где написано, что ты хочешь сделать с базой: «создать таблицу users» или «добавить колонку email». Как список дел на ремонт.
• Версионирование — чтобы не было ебалы в голове, все файлы называются по правилу: V1__, V2__. Flyway смотрит на цифру и понимает, что V1 делаем раньше, чем V2. Гениально и просто, как тапок.
• История — а чтобы не обосраться и не применить одно и то же дважды, Flyway создаёт в твоей же базе специальную таблицу-журнал flyway_schema_history. Там он помечает, какие скрипты уже выполнил, а какие нет. Это как чек-лист у прораба — всё под контролем, блядь.

Как это выглядит в проекте?

Обычно ты кидаешь SQL-файлы в определённую папку, и всё.

resources/
└── db/
    └── migration/
        ├── V1__create_user_table.sql      # Первый — создаём таблицу
        ├── V2__add_email_to_user.sql      # Второй — добавляем почту
        └── V3__insert_initial_data.sql    # Третий — закидываем тестовых юзеров

А внутри файла — обычный SQL, ничего сверхъестественного.

-- V1__create_user_table.sql
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    username VARCHAR(50) NOT NULL UNIQUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Как прикрутить к Spring Boot?

В application.yml пишешь пару строк, и он уже работает. Главное — путь к скриптам указать правильно, а то он их не найдёт и будет тихо охуевать.

spring:
  flyway:
    enabled: true  # Включить, чтобы он вообще стартанул
    locations: classpath:db/migration  # Где искать твои священные скрипты
    baseline-on-migrate: true  # Если таблицы истории нет — он её сам создаст, красава

И зачем этот геморрой, спросишь?

А вот зачем, ёпта:

1. База под контролем версий. Твои миграции лежат в гите рядом с кодом. Поднял проект с нуля — запустил Flyway, и база сама собралась до нужного состояния. Магия, блядь.
2. Воспроизводимость. На тестовом стенде, на проде, у дяди Васи в гараже — состояние базы будет одинаковым (если, конечно, не лезть в неё руками, как обезьяна в шоколад).
3. Автоматизация в CI/CD. При сборке проекта или деплое можно автоматически накатывать миграции. Никаких ручных скриптов по пятницам в пять вечера, после которых всё летит в пизду.
4. Откат изменений. Есть даже механизм откатных миграций (undo, с префиксом U). Но это, брат, опасная тема, как игра в русскую рулетку с полуразобранным автоматом. Пользоваться нужно с охуенной осторожностью и только если очень надо.

В общем, если не хочешь, чтобы твоя база данных превратилась в свалку непонятных изменений, где последний, кто помнил, зачем нужна колонка is_deleted_2, уже уволился — бери Flyway на вооружение. Оно того стоит, ей-богу.