Версия программы и состояние данных различаются
Файл приложения описывает, как читать и изменять информацию. Данные содержат уже накопленные записи. Возврат прежнего файла сам по себе не отменяет созданные заказы, изменённые значения или отправленные уведомления. Даже специализированный механизм отката имеет границы. Например, откат Deployment в Kubernetes возвращает прежний шаблон подов, но не выполняет автоматическое восстановление базы данных. Сначала нужно назвать объект отката, а затем перечислить всё, что остаётся за его пределами. Иначе слово вернуть скрывает несколько разных операций.
Совместимость проверяется в обе стороны
Представим две версии справочника. Первая читает имя из поля full_name, вторая из display_name. Если при переходе старое поле удалили, возврат первой версии не восстановит её способность читать записи. Сохранение обоих полей может быть частью перехода, но одного наличия недостаточно: нужно определить, как поддерживается согласованность значений при изменениях. Если новая версия обновляет только одно поле, старая может показывать устаревшее имя. Поэтому проверяют чтение и запись обеих версий, а также данные, созданные каждой из них.
Испытание должно включать обратный переход
Проверка только новой версии на старых данных отвечает на ограниченный вопрос. Отдельный учебный сценарий включает создание записи старой версией, работу новой, её изменение данных и возвращение старой. Для распределённой системы также важно рассмотреть период, когда разные версии действуют одновременно. В плане выпуска полезно заранее указать признаки успешной проверки и изменения, после которых привычный откат уже неприменим. Наличие резервной копии требует собственной проверки восстановления и допустимости потери новых записей; оно не превращает любой переход в безопасный.
Попробуйте на практике
Постройте матрицу совместимости вымышленного справочника на листе. Все данные учебные, выполнять миграцию или запускать приложения не нужно.
- Обозначьте версию А: читает и изменяет full_name. Версия Б читает и изменяет display_name. Запишите, что никаких дополнительных механизмов синхронизации в исходном условии нет.
- Рассмотрите состояние первое: сохранено только full_name. Затем состояние второе: сохранено только display_name. Для каждой версии отметьте, есть ли требуемое ей поле.
- Рассмотрите состояние третье: оба поля присутствуют и первоначально равны. Версия Б меняет только display_name. Объясните, почему наличие двух полей ещё не гарантирует одинаковый результат чтения.
- Сформулируйте два требования к проверке перехода: работоспособность после возврата версии и согласованность данных после записей. Отдельно перечислите неизвестные детали реализации, которые нельзя заменить предположением.
Как проверить результат. В первом состоянии нужное поле есть у А, во втором у Б. В третьем обе версии находят свои поля, но после изменения Б значения могут расходиться. Вы различили доступность поля, актуальность значения и возврат версии приложения.
Частые вопросы
Можно ли считать успешный запуск доказательством безопасного отката?
Нет. Процесс может запуститься, но неверно читать новые записи или показывать устаревшие значения. Проверка должна затрагивать значимые операции и данные, а не только факт запуска.
Нужно ли при любом сбое немедленно возвращать старую версию?
Решение зависит от характера изменения, состояния данных и подготовленного плана восстановления. Иногда возврат усугубляет несовместимость. Универсальная команда без знания системы этого выбора не заменяет.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.