Как реализовать миграции базы данных?

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

Понимаете ли вы, что миграции это версионирование схемы, и знаете ли правила безопасного применения на живой базе.

Как отвечать

Миграция это скрипт изменения схемы, лежащий в репозитории рядом с кодом и применяемый инструментом, который помнит, что уже накатано. В Python это Alembic (для SQLAlchemy) или встроенные миграции Django.

Базовые правила:

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

Что важно на живой базе:

• добавление колонки без значения по умолчанию мгновенно, а с DEFAULT на старых версиях PostgreSQL переписывало таблицу целиком;
• индекс строят через CREATE INDEX CONCURRENTLY, обычная команда блокирует запись;
• несовместимые изменения разбивают на шаги: сначала добавить новое поле и писать в оба, потом перенести данные, потом убрать старое. Тогда старая и новая версии кода работают одновременно, и выкладка не требует остановки;
• бэкофилл пачками, а не одним UPDATE на миллионы строк.

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

Правят уже применённую миграцию.

Доверяют автогенерации и теряют данные при переименовании.

Строят индекс на большой таблице обычной командой и блокируют прод.

Делают несовместимое изменение одним шагом и получают ошибки во время выкладки.