Собранная программа может запускаться, но показывать клиенту неверный статус заявки. Поэтому решение о выпуске связывают не только с пакетом файлов, но и с конкретным действием пользователя. До переключения определяют условия допуска, после — проверяют рабочий результат.
Разберём учебный пример: в кабинете меняется выдача статуса заявки. Планируется переход с rev-A на rev-B. Это условные обозначения версий, а не описание выполненного выпуска АИС Сокол.
Паспорт одного выпуска
Паспорт связывает изменение, условия переключения и проверку результата. Он нужен участникам одного выпуска, а не заменяет документацию всей системы.
В учебном примере состав можно записать так:
| Поле | Содержание учебного паспорта |
|---|---|
| Изменение и граница | Обновить выдачу статуса заявки в кабинете. Порядок обработки заявок и расчёты не меняются. |
| Ожидаемая текущая версия | rev-A с конфигурацией cfg-A. Перед переключением нужно подтвердить именно это состояние. |
| Целевая версия | rev-B с конфигурацией cfg-B. Используется проверенный пакет, без пересборки во время переключения. |
| Состав пакета | Экран статуса и обработчик его выдачи. Перечень файлов и контрольная сумма относятся к выбранной сборке rev-B. |
| Конфигурация | cfg-B содержит настройки подключения к сервису заявок. Рабочие значения и секреты передаются по согласованному порядку, не в публичном паспорте. |
| Зависимости | Сервис обработки заявок и фоновые уведомления. В этом примере формат ответа и схема данных сохраняются; отдельная миграция не входит в выпуск. |
| Пользовательский результат | Клиент открывает свою заявку и видит статус, который ответственный зафиксировал в системе обработки. |
| Кто переключает | Назначенный исполнитель выпуска. Он сверяет пакет и условия, выполняет согласованное переключение и записывает его исход. |
| Кто решает об остановке | Технический ответственный. Правильность показанного статуса подтверждает владелец процесса обработки заявок. |
| Условия допуска | Подтверждены проверки в отдельной среде, состав копии и возможность восстановления; согласованы окно, допустимый простой и ограничения записи. |
| Граница возврата | Возврат rev-A и cfg-A допустим только после проверки совместимости с текущими данными и учёта операций после переключения. |
В отдельной среде проверяют совместимость старой и новой версии с текущими данными и подключёнными сервисами. Если предусмотрена их совместная работа, контрольный сценарий проходят и в таком сочетании.
Если в фактическом проекте нужна миграция, её включают в зависимости паспорта. Выпуск приложения не должен опережать состояние данных, с которым оно умеет работать. Подробная сверка переноса — отдельная задача, а здесь важен её результат как условие допуска.
До начала участники также согласуют, кто вправе остановить работу и какие материалы получит заказчик. Общий порядок описан на странице «Как принимаем и передаём результат».
Что должна покрывать резервная копия
Для выбранного изменения перечислите, что понадобится восстановить: прежний пакет приложения, конфигурацию, затронутые данные и связанные файлы. В примере с заявками это могут быть записи заявок, история статусов и вложения. Состав копии зависит от границ возможного восстановления.
Зафиксируйте момент копии и её охват. Если данные и файлы копируются раздельно, нужно понимать, к какому состоянию относится каждая часть и как проверить их связи. Отдельно определяют, где учитываются заявки и изменения статусов, появившиеся после копирования.
Доступ к копии получают только назначенные участники. В план проверки включают восстановление в отдельной согласованной среде: открыть контрольную заявку, проверить историю и связь с вложениями. Автоматические обращения к рабочим сервисам и реальные уведомления при такой проверке не запускают.
Наличие файла резервной копии не подтверждает, что из него удалось восстановить нужное состояние. Для допуска к выпуску требуется результат предусмотренной проверки, а не только отметка о создании файла. В этой статье описан план, не проведённое восстановление.
Почему перед переключением проверяют ожидаемую ревизию
Пока команда готовила rev-B, другой участник мог выпустить rev-C. Перезаписать её по старому плану rev-A → rev-B — значит проигнорировать изменение, которого в плане не было.
Требование к переключению формулируют так: заменить текущую ревизию на целевую только при совпадении с ожидаемой текущей ревизией. При rev-C вместо rev-A выпуск останавливают, выясняют состав изменения и пересогласуют переход.
Такое требование называют условной заменой по ожидаемому значению, или CAS. Но последовательность «прочитать → сравнить → записать» сама по себе не доказывает атомарность: между сравнением и записью состояние может поменяться. Возможность условного изменения проверяют для конкретного механизма переключения, включая одновременные попытки. Одной договорённости в документе недостаточно.
Пример проверки ожидаемого старого значения есть в документации Git update-ref. Это операция над ссылкой Git, а не готовый способ атомарно переключить приложение, конфигурацию и базу данных. Переносить её свойства на весь выпуск нельзя.
Если ответ о переключении потерян, исход остаётся неизвестным. Перед повторным действием выясняют фактически активную версию и конфигурацию. Повторять переключение вслепую или объявлять его успешным по отсутствию ошибки нельзя.
Матрица решений: продолжить, остановить или восстановить
До переключения технический ответственный сопоставляет результаты проверок, ревизию, конфигурацию и зависимости с паспортом. Начать переход можно только в согласованном окне и при выполнении всех условий. Неполная проверка не считается положительной.
Ниже — учебная матрица. Она задаёт решения для разных исходов, а не сообщает, что проверки уже выполнены.
| Состояние | Решение | Основание и запись |
|---|---|---|
| Обязательная проверка не пройдена или её результат неизвестен | Не переключать. Уточнить причину и повторить нужную проверку после исправления. | Сохранить результат проверки, затронутый сценарий и решение технического ответственного. |
| Вместо ожидаемой rev-A обнаружена rev-C | Остановить переход. Не затирать новую ревизию; пересогласовать состав выпуска. | Записать ожидаемое и обнаруженное состояния. Проверить, какие изменения появились. |
| После перехода на rev-B клиент видит неверный статус | Не расширять выпуск. Выбрать восстановление или исправление по подготовленному плану с учётом новых операций. | Зафиксировать версию, расхождение статуса, состояние данных и решение ответственного. |
| Условия допуска выполнены, после переключения контрольный сценарий подтверждён | Зафиксировать рабочий результат и продолжить согласованное наблюдение. | Записать rev-B, конфигурацию, результат проверки, время и участника, подтвердившего его. |
Где заканчивается простой откат
Возврат кода и конфигурации не возвращает автоматически данные. После перехода на rev-B могли появиться новые заявки и статусы. Восстановление старой копии без их учёта способно убрать уже принятые операции из рабочего состояния.
Поэтому перед возвратом проверяют две вещи: сможет ли rev-A работать с текущими данными и как сохранить операции после переключения. Возможность вернуть только приложение определяется этими условиями, а не наличием прежнего пакета.
Для необратимых изменений нужен отдельный план восстановления или корректирующая миграция. Иногда восстановление приходится выполнять без простого возврата версии приложения. Выбор, допустимый простой и ограничения записи согласуют заранее, а при неизвестном состоянии сначала собирают сведения для решения. Резервная копия — часть этого плана, не весь план.
Как подтвердить рабочий результат
После переключения выполняют согласованный короткий сценарий. В нашем примере ответственный фиксирует статус контрольной заявки в системе обработки, а клиентская роль открывает эту же заявку в кабинете. Сверяют саму запись, отображённый статус и допустимость доступа. Не создают реальные обращения или уведомления ради непредусмотренной проверки.
Рядом с результатом записывают активную версию, конфигурацию, время проверки и подтвердившего участника. Наблюдение после выпуска должно показывать, продолжается ли выбранный процесс. Если состояние неизвестно или результат неверен, решение принимают по матрице, а не по факту успешной сборки.
По теме: Критерии проверки рабочего сценария · Отдельная проверка миграции данных · Когда уведомление требует реакции.
Для обсуждения выпуска опишите одно изменение, затронутые данные и действие, которое должно работать после переключения. Пароли, закрытые журналы и рабочие копии через публичную форму не передавайте.
