Откатить код после миграции базы данных безопасно можно только тогда, когда старая версия приложения понимает новую схему и данные. Поэтому план отката готовят до релиза: сначала расширяют схему без удаления старого контракта, затем переводят код и данные, а несовместимые изменения оставляют на отдельный этап.
Возврат предыдущей версии приложения не возвращает прежнюю структуру БД. Если миграция уже удалила поле, изменила допустимые значения или необратимо преобразовала данные, старый код может не запуститься либо начать записывать некорректные данные.
Почему откат кода и откат БД — разные операции
У приложения и базы есть независимые версии. Проверять нужно не только пары «старый код — старая схема» и «новый код — новая схема», но и аварийную комбинацию: старый код с уже применённой новой схемой.
Чаще всего откат ломают:
- удаление или переименование столбца;
- обязательное поле без значения для старого кода;
- изменение типа, формата или смысла данных;
- новые статусы, которых прежняя версия не знает;
- перенос данных с немедленным удалением исходного поля;
- одновременная работа старых и новых фоновых процессов.
До релиза нужен явный ответ: продолжит ли старая версия читать и записывать данные после миграции и поймёт ли она записи, созданные новой версией.
Используйте схему expand — migrate — contract
Безопасное изменение делят на несколько этапов.
1. Expand: добавьте новое, не удаляя старое
Сначала добавляют поле или таблицу так, чтобы действующий код продолжал работать. Новое поле временно допускает безопасное значение для операций старой версии.
На этом этапе нельзя удалять объект, который использует текущий код.
2. Deploy: выпустите совместимый код
Новая версия умеет работать с переходной схемой. При необходимости она временно записывает оба представления данных, а чтение переключается отдельно.
Если веб-процессы и фоновые задачи обновляются не одновременно, каждая активная версия должна понимать общую схему.
3. Migrate: перенесите данные
Существующие записи переносят отдельной управляемой операцией. Для большой таблицы заранее определяют размер порций, влияние на блокировки, возможность паузы и способ продолжить после ошибки.
Проверяйте не только число строк, но и смысловое соответствие данных: одинаковое количество записей само по себе не доказывает корректность преобразования.
4. Contract: удалите старое позже
Старое поле удаляют, когда новый код стабильно работает, перенос завершён, старые процессы остановлены, а возврат к прежней версии больше не входит в план быстрого отката.
Преждевременный этап contract превращает откат приложения в восстановление БД.
Пример: замена поля статуса
Допустим, приложение должно перейти с текстового статуса заказа на новый код. В первом релизе добавляют поле и начинают записывать оба значения, не меняя чтение. Затем заполняют новое поле для прежних заказов и проверяют соответствие.
В следующем релизе чтение переводят на новое поле, сохраняя старое. При возврате прежняя версия всё ещё увидит знакомые данные. Исходное поле удаляют отдельным релизом, когда быстрый откат старого кода уже не нужен.
Как проверить совместимость до production
Испытание проводят на копии актуальной структуры с безопасными тестовыми или обезличенными данными. Используйте тот же артефакт миграции, который пойдёт в релиз, а не собранный вручную аналог.
- Примените расширяющую миграцию к копии текущей БД.
- Запустите на новой схеме прежнюю версию приложения.
- Проверьте чтение и запись, фоновые задачи и критичные интеграции.
- Создайте данные новой версией и проверьте реакцию старой.
- Верните старый код без обратной миграции и повторите критический сценарий.
- Испытайте продолжение переноса данных после прерывания.
- Зафиксируйте условия отката кода, исправления вперёд и восстановления данных.
Проверка пройдена, если известны совместимая пара версий, точка необратимости, ответственный за решение и сценарий, подтверждающий восстановление работы.
Порядок действий во время релиза
Сохраните идентификаторы версии приложения и применённых миграций. Выполните расширяющую часть схемы, разверните совместимый код и проверьте ключевые страницы и операции.
Для веб-части используйте smoke-тест после релиза. Он проверяет наблюдаемые сценарии, но не заменяет контроль записей в БД, фоновых задач и совместимости старой версии.
После первичной проверки запускают перенос данных. Несовместимое удаление откладывают до отдельного окна, когда переходная версия больше не нужна.
Web-Puls может регулярно проверять доступность критичных публичных URL и сообщать о внешнем сбое. Мониторинг показывает симптом после релиза, но не проверяет миграции, целостность данных или возможность отката.
Что делать, если откат понадобился
Остановите следующие шаги миграции и определите фактическое состояние: какая версия кода работает, что применено, завершён ли перенос и успела ли новая версия записать данные.
Если старая версия испытана с расширенной схемой, верните только код и повторите критические проверки. Если совместимости нет, используйте заранее проверенное исправление вперёд либо процедуру восстановления данных. Не запускайте обратную миграцию вслепую: она может удалить новые записи или повторно преобразовать данные.
После восстановления проверьте запись данных, очереди, задания по расписанию и затронутые интеграции, а не только главную страницу.
Когда нужна помощь специалиста
Самостоятельного плана достаточно для небольшого добавочного изменения с проверенным возвратом. Если миграция затрагивает большую таблицу, блокировки, репликацию, несколько версий приложения или необратимое преобразование, безопасный порядок лучше определить до релиза.
Если сбой уже произошёл, отправьте описание релиза и симптомов через форму профессиональной поддержки. Не прикладывайте пароли, ключи, дампы с персональными данными и приватные адреса.
Вывод
Надёжный откат начинается с совместимой переходной схемы. Разделите добавление, перенос и удаление, испытайте старый код на расширенной БД и заранее обозначьте точку, после которой возврат приложения заменяется процедурой восстановления данных.