Короткий ответ Нужно заранее спроектировать миграцию так, чтобы она была обратно совместима со старой версией кода хотя бы некоторое время, и подготовить проверенный план отката кода отдельно от отката данных, поскольку откатить миграцию БД обычно сложнее, чем откатить деплой кода. Как это работает подробнее Откат кода (деплой предыдущей версии) обычно быстрый и безопасный сам по себе, но если новая версия уже выполнила несовместимую миграцию (например, удалила колонку), старая версия кода может перестать работать после отката. Поэтому миграции проектируют так, чтобы можно было откатить код, оставив схему БД в состоянии, совместимом со старой версией (подход expand/contract из предыдущих вопросов). Пример кода Что использовать на практике Практика. Перед релизом стоит явно проверить план отката: что произойдёт, если откатить только код (сработает ли он со свежей схемой), и что делать, если проблема обнаружена уже после того, как контрактный шаг миграции (удаление старых полей) выполнен. Для рискованных релизо
Загрузка…
