Как выпускать миграции базы данных под feature flag?

Когда новая функциональность включается через feature flag, схема базы данных должна поддерживать оба состояния одновременно: и старое поведение, и новое. Если миграция сразу удалит колонку или переименует поле, старый код, который ещё работает у части пользователей, упадёт. Поэтому миграции выпускают по принципу expand and contract: сначала расширяем схему, потом переносим данные и код, и только затем сжимаем.

Основные шаги

1. Expand: добавить новые колонки, таблицы или индексы, не удаляя старые. Миграция должна быть безопасной для старого кода.
2. Dual write: новый код пишет и в старое, и в новое место, чтобы данные не терялись.
3. Backfill: отдельным скриптом перенести исторические данные в новую структуру.
4. Switch: включить feature flag, чтобы чтение пошло из новой структуры.
5. Contract: после полного раската и стабилизации удалить старые колонки отдельной миграцией.

Пример миграции

-- Шаг 1: expand, добавляем новую колонку
ALTER TABLE users ADD COLUMN full_name TEXT;

-- Шаг 2: backfill данных
UPDATE users SET full_name = first_name || ' ' || last_name
WHERE full_name IS NULL;

-- Шаг 3: после раската флага удаляем старые колонки
ALTER TABLE users DROP COLUMN first_name;
ALTER TABLE users DROP COLUMN last_name;

Правила безопасности

• Миграции должны быть идемпотентными и обратимыми, где это возможно.
• Не блокировать таблицы надолго: используйте CONCURRENTLY для индексов в PostgreSQL.
• Флаг управляет кодом, а не схемой: схема должна быть совместима с обоими состояниями.
• Удаление старых полей делайте только после того, как флаг раскатан на 100% и прошло достаточно времени.

Такой подход позволяет деплоить миграции и код независимо, откатывать функциональность без отката схемы и избегать простоя. Он особенно полезен в командах с непрерывным деплоем и большим количеством пользователей.