Кто пишет миграции в проекте

Что проверяют

Как в команде устроена работа со схемой базы и понимаете ли вы, что миграция это такой же код, со своим ревью и своими рисками. Следом спрашивают, как миграция доезжает до прода и что будет со старыми инстансами сервиса во время выкладки.

Как отвечать

В большинстве Go-команд миграцию пишет тот разработчик, чья задача меняет схему, в том же пулл-реквесте, что и код. Дальше расскажите, как это устроено у вас:

• инструмент: golang-migrate (пары файлов .up.sql и .down.sql с номером или меткой времени), goose (SQL- или Go-миграции, разметка -- +goose Up), декларативный Atlas;
• ревью: миграцию смотрит второй разработчик, а в крупных компаниях ещё DBA или владелец базы. Проверяют блокировки, индексы, объём затронутых строк;
• применение: отдельный шаг в CI/CD или Kubernetes Job перед выкладкой новой версии, а не вызов при старте каждой реплики. Многие инструменты берут блокировку, но долгая миграция при старте всё равно задерживает поды и валит проверки готовности;
• совместимость: во время rolling update старая и новая версии сервиса работают одновременно, поэтому изменения идут по схеме expand/contract. Сначала добавляется новая колонка и код пишет в обе, затем переносятся данные, и только отдельным релизом удаляется старое.

Про большие таблицы стоит сказать отдельно. CREATE INDEX CONCURRENTLY в PostgreSQL нельзя выполнять внутри транзакции, поэтому в goose такую миграцию помечают -- +goose NO TRANSACTION. Бэкфилл идёт пачками, а не одним UPDATE на всю таблицу. Хорошо, если назовёте случай из своего проекта: какая миграция была самой рискованной и как её раскатывали.

Где спотыкаются

Говорят «миграции пишет DBA» или «их генерирует ORM» и не могут объяснить, кто отвечает за их корректность. Сгенерированный код тоже нужно читать.

Переименовывают или удаляют колонку в одном релизе с кодом. Пока старые поды ещё обслуживают трафик, они падают на отсутствующей колонке.

Полагаются на down-миграции как на откат. Удалённые данные down не вернёт, настоящий план отката это обратно совместимые изменения и бэкап.