Стратегия развёртывания и отката¶
Требования применяются к выполнению deployment, продвижения, rollback и
фиксации результата в non-production и production целях. Уровни
обязательности определены в корневом README.md.
INF-REL-001. План поставки¶
Уровень: MUST
Применяется к: production release
До запуска должны быть определены release identifier image, изменение конфигурации,
миграции, критерии успеха, наблюдаемое окно и выбранное действие при отказе.
Критерии и действия должны реализовывать применимые
architecture:DEP-ROL-001–DEP-ROL-005, а не задавать новую семантику
готовности приложения.
Обоснование¶
Факт запуска workload не доказывает корректность версии.
Проверка¶
- review GitLab deployment metadata;
- тест нарушения каждого release gate.
Исключения¶
Не допускаются.
INF-REL-002. Rolling update Kubernetes¶
Уровень: MUST
Применяется к: Kubernetes Deployment в профиле high-availability
Стратегия должна сохранять как минимум один готовый экземпляр и достаточную
ёмкость во время замены. maxUnavailable, maxSurge, readiness и progress
deadline должны иметь явные значения, вычисленные для числа реплик и
architecture:DEP-ROL-001. Неуспешный progress deadline должен завершать job с
ошибкой и останавливать дальнейшее продвижение.
Обоснование¶
Настройки по умолчанию могут не соответствовать числу реплик и ёмкости.
Проверка¶
- rollout под нагрузкой;
- тест зависшего запуска и недостаточной ёмкости.
Исключения¶
Stateful workload MAY использовать другую поэтапную стратегию с тем же проверяемым результатом.
INF-REL-003. Single-instance deployment¶
Уровень: MUST
Применяется к: production-цели single-instance
Владелец должен явно определить ожидаемое окно недоступности при deployment и восстановлении узла. Pipeline должен исключать одновременный запуск двух экземпляров, если приложение не поддерживает конкурентную работу.
Обоснование¶
Single-instance — осознанный профиль, а не неявное обещание доступности.
Проверка¶
- сопоставление runbook и SLO;
- тест повторного запуска и блокировки второго экземпляра.
Исключения¶
Не допускаются.
INF-REL-004. Проверяемый rollback или roll-forward¶
Уровень: MUST
Применяется к: каждой production-поставке
Deployment automation должна исполнять выбранный проектом rollback или
roll-forward по architecture:DEP-ROL-004 с сохранёнными release identifier
image и commit конфигурации. Допустимость возврата версии данных должна браться из
architecture:BE-MIG-001–BE-MIG-004; инфраструктурный сценарий не должен
вводить собственное правило совместимости.
Обоснование¶
Непроверенный rollback способен усилить инцидент и повредить данные.
Проверка¶
- rehearsal в non-production;
- проверка совместимости схемы и конфигурации.
Исключения¶
Roll-forward допустим вместо rollback при указанном бюджете восстановления.
INF-REL-005. Фиксация результата¶
Уровень: MUST
Применяется к: завершившемуся production deployment
GitLab environment или GitOps status должен сохранять цель, release identifier image, commit конфигурации, pipeline, время, исполнителя и результат. Неуспешный deployment не должен отмечаться как поставленная версия.
Обоснование¶
Операционный аудит требует точного ответа, что и когда работает.
Проверка¶
- сверка runtime image с GitLab/GitOps записью;
- тест неуспешного rollout.
Исключения¶
Не допускаются.
INF-REL-006. Порядок конфигурации, секрета и приложения¶
Уровень: MUST
Применяется к: release, изменяющему более одного из image, ConfigMap, Secret, schema данных или route
План должен определять совместимый порядок изменения и точку, после которой
rollback старой версии запрещён. Старый и новый экземпляры должны получать
совместимые значения во время смешанной работы по
architecture:DEP-ROL-002. Удаление старого значения или route допускается
только после отсутствия его потребителей.
Обоснование¶
Независимо корректные изменения могут быть несовместимы при другом порядке.
Проверка¶
- тест каждой промежуточной стадии со смешанными версиями;
- rollback до и после точки необратимости.
Исключения¶
Атомарная single-instance поставка MAY не иметь смешанных версий, но должна соблюдать заявленное окно недоступности.
INF-REL-007. Compose release¶
Уровень: MUST
Применяется к: удалённой Docker Compose-цели
Pipeline должен сначала получить и проверить все новые release images, затем
выполнить ограниченное по времени compose up или эквивалент, дождаться
healthchecks и сверить работающие release identifiers. При ошибке старые работоспособные
containers не должны удаляться до запуска rollback либо явного объявления
недоступности.
Обоснование¶
Последовательный pull после остановки создаёт лишнее окно недоступности и необратимое частичное состояние.
Проверка¶
- недоступный Registry и ошибочный healthcheck;
- сверка container image после успешного и неуспешного deployment.
Исключения¶
Остановка до запуска допустима, если этого требует single-writer приложение и окно зафиксировано.
INF-REL-008. Очистка старых revisions¶
Уровень: MUST
Применяется к: завершённому release
История ReplicaSet, Helm release, Compose containers и deployment artifacts
должна иметь численный retention. Очистка не должна удалять revision,
необходимую для действующего rollback, расследования или аудита по
INF-ART-005.
Обоснование¶
Неограниченная история расходует ресурсы, а преждевременная очистка ломает восстановление.
Проверка¶
- проверка retention после нескольких releases;
- rehearsal rollback к самой старой сохраняемой revision.
Исключения¶
Не допускаются.