Проверка изменений¶
Требования применяются к изменениям запускаемых и публикуемых компонентов.
Уровни обязательности определены в корневом README.md.
В этом документе consumer contract — версионируемое машинно-проверяемое ожидание конкретного consumer к используемой части контракта provider.
DEV-VER-001. Проверяемый результат изменения¶
Уровень: MUST
Применяется к: каждому изменению поведения, контракта, данных или сборки
До merge должен существовать объективный способ подтвердить изменённый результат. Проверка MAY быть статическим анализом, валидацией схемы, автоматизированным тестом, сравнением артефакта или ограниченным review.
Обоснование¶
Тип проверки должен соответствовать риску, а не заранее выбранному инструменту.
Проверка¶
- сопоставление изменённого результата и evidence в merge request;
- контролируемое нарушение проверяемого свойства.
Исключения¶
Изменение только ненормативного текста MAY проверяться Markdown-проверками и review.
DEV-VER-002. Усиленная проверка существенного риска¶
Уровень: MUST
Применяется к: изменению security-границы, публичного контракта, миграции, целостности данных или восстановления
Изменение должно иметь автоматизированную проверку нарушаемого инварианта и отказного сценария. Если автоматизация технически невозможна, ADR должен зафиксировать причину, ограниченную ручную проверку и срок устранения пробела.
Обоснование¶
Для последствий, определённых DOC-CLR-010, одного субъективного review
недостаточно.
Проверка¶
- автоматизированный негативный сценарий;
- проверка связи теста с контрактом или инвариантом;
- review ADR при отсутствии автоматизации.
Исключения¶
Только через ADR с владельцем и сроком.
DEV-VER-003. Назначение обязательных проверок¶
Уровень: MUST
Применяется к: CI-проверкам проекта
Проект должен явно разделять проверки, блокирующие merge, блокирующие release и информационные проверки. Успех обязательной проверки должен означать выполнение всех заявленных действий и наличие требуемого результата. Неожиданный пропуск, отмена, timeout, частичное выполнение, отсутствие обязательного отчёта или неуспешный результат не должны считаться успешной проверкой.
Обоснование¶
Явное назначение не позволяет принять отсутствие результата за доказательство готовности.
Проверка¶
- review правил pipeline и protected branch;
- контролируемый skip, cancel, timeout, частичное выполнение и failure обязательного job;
- проверка отсутствующего обязательного отчёта.
Исключения¶
Экстренный обход выполняется только по OPS-INC-003 с последующей проверкой
поставленного состояния.
Условная проверка MAY быть пропущена, если условие основано на проверяемом признаке неприменимости и пропуск не учитывается как выполненная проверка.
DEV-VER-004. Нестабильная проверка¶
Уровень: MUST
Применяется к: проверке, дающей разные результаты для одинаковых входов
Первый неуспешный результат должен оставаться видимым. Retry MAY использоваться для диагностики, но не должен автоматически изменять обязательный итог на успешный. До исправления проверка должна блокировать соответствующую поставку либо быть выведена из обязательного набора с владельцем, риском и сроком.
Обоснование¶
Скрытый retry маскирует дефект продукта или инфраструктуры и создаёт ложный успех.
Проверка¶
- review настроек retry;
- сопоставление первого и итогового результата;
- проверка записи о временно выведенной проверке.
Исключения¶
Повтор infrastructure job MAY заменить результат, если доказано, что код проверки не начал выполняться.
DEV-VER-005. Достаточность без дублирования¶
Уровень: SHOULD
Применяется к: выбору нескольких способов проверки одного изменения
Следует использовать минимальный набор проверок, подтверждающий независимые риски изменения. Одинаковый инвариант не следует обязательно повторять на unit-, integration- и e2e-уровнях.
Обоснование¶
Дублирование увеличивает время pipeline и сопровождения без пропорционального роста уверенности.
Проверка¶
- сопоставление каждой проверки с отдельным риском;
- поиск одинаковых assertions на разных уровнях.
Исключения¶
Повторная проверка MAY использоваться для критичного сквозного сценария или контроля самой тестовой границы.
DEV-VER-006. Детерминированная автоматизированная проверка¶
Уровень: MUST
Применяется к: автоматизированной проверке backend-, worker-, data-pipeline- или frontend-компонента, используемой как evidence для merge или release
При одинаковых коде, конфигурации, seed и входных данных проверка должна давать одинаковый результат. Время, случайность, порядок конкурентного выполнения, сеть и изменяемая внешняя система должны контролироваться либо проверяться без зависимости от конкретного значения или порядка.
Вероятностная, нагрузочная или performance-проверка должна до запуска задавать
объём выборки, численный критерий результата и допустимый разброс. Повтор
неуспешного запуска не должен изменять обязательный итог на успешный в обход
DEV-VER-004.
Обоснование¶
Невоспроизводимый результат нельзя независимо проверить или использовать как обязательный gate поставки.
Проверка¶
- повторный запуск с теми же входами и seed;
- запуск набора в случайном порядке и с допустимой параллельностью;
- контролируемое изменение времени, сети и доступности внешней зависимости;
- проверка статистического критерия для вероятностного результата.
Исключения¶
Production canary MAY использовать текущий трафик вместо фиксированных входов,
если решение основано на заранее заданном окне, минимальном объёме и численных
порогах по DEP-ROL-003.
DEV-VER-007. Изоляция данных проверки¶
Уровень: MUST
Применяется к: автоматизированной проверке backend-, worker-, data-pipeline- или frontend-компонента вне production, которая читает или изменяет данные
Проверка должна использовать синтетические данные, отдельные непроизводственные credentials и изолированную область состояния. Она не должна использовать production-секреты, необработанные production-данные или изменяющий доступ к production-системе.
Каждый запуск должен создавать известное начальное состояние и после завершения удалять созданные данные либо использовать уникальную область, исключающую влияние на другой запуск. Прерванный запуск не должен делать последующий результат зависимым от оставшегося состояния.
Обоснование¶
Общая или производственная среда проверки создаёт риск утечки, повреждения данных и ложного результата из-за взаимного влияния запусков.
Проверка¶
- secret scanning проверок и CI-конфигурации;
- сопоставление credentials и endpoints с непроизводственной целью;
- параллельный запуск и повтор после принудительного прерывания;
- проверка очистки или уникальности области состояния.
Исключения¶
Минимизированная и деперсонализированная копия production-данных MAY
использоваться по политике DATA-CLS-001 с отдельными credentials, retention и
проверяемым удалением. Production-секреты и изменяющий production-доступ не
допускаются.
DEV-VER-008. Автоматическая проверка архитектурного инварианта¶
Уровень: MUST
Применяется к: архитектурному инварианту принятого ADR или применимого требования, который определяется из исходного кода, dependency graph, schema, конфигурации или release-артефакта
Проект должен иметь детерминированную автоматизированную проверку инварианта. Проверка должна выполняться до merge либо release в зависимости от момента, когда существует проверяемое представление, и блокировать соответствующий переход при нарушении.
Имя проверки и контролируемая область должны быть связаны с requirement ID или ADR. Изменение инварианта и проверки должно поставляться одним merge request.
Обоснование¶
Машинно наблюдаемая граница, проверяемая только общим review, незаметно разрушается при последующих изменениях.
Проверка¶
- контролируемое нарушение dependency direction, contract или ownership rule;
- проверка блокировки merge либо release;
- сопоставление check metadata с ID или ADR и контролируемой областью.
Исключения¶
Если требуемое представление технически недоступно автоматизации, применяется
DEV-VER-009.
DEV-VER-009. Ограниченная ручная проверка инварианта¶
Уровень: MUST
Применяется к: архитектурному инварианту, который технически невозможно проверить автоматически
Принятый ADR должен определить техническую причину отсутствия автоматизации, точный перечень проверяемых файлов или артефактов, критерий успешного результата, ответственную роль, сохраняемое evidence и условие повторной оценки автоматизации. Merge request должен содержать результат этой проверки для фактически изменённого diff.
Формулировки без закрытого критерия, включая «проверить архитектуру» или «проверить корректность», не должны считаться выполненной проверкой.
Обоснование¶
Ограниченный предмет и evidence позволяют воспроизвести ручное решение и не превращают невозможность автоматизации в постоянный бесконтрольный обход.
Проверка¶
- review полноты ADR и области ручной проверки;
- повтор проверки другим уполномоченным reviewer по тому же diff;
- проверка условия пересмотра при изменении toolchain или артефакта.
Исключения¶
Не допускаются для отсутствующего критерия или evidence.
DEV-VER-010. Минимальный consumer contract¶
Уровень: MUST
Применяется к: consumer contract, используемому как evidence совместимости независимо поставляемых consumer и provider
Consumer contract должен идентифицировать consumer, provider, версию или commit контракта и поддерживаемую версию интерфейса provider. Он должен описывать только фактически используемые операции, поля, значения и классы ошибок, а его ожидания должны проверяться автоматизированным тестом реального consumer либо общего adapter, выполняемого этим consumer.
Поле или вариант ответа, который consumer не использует, не должен становиться обязательным ожиданием только из-за присутствия в полном контракте provider. Отсутствие используемого обязательного результата или изменение его смысла должно завершать проверку ошибкой.
Обоснование¶
Минимальный контракт обнаруживает несовместимость для действующего consumer, не запрещая provider совместимо расширять неиспользуемую часть интерфейса.
Проверка¶
- сопоставление ожиданий с вызовами и assertions теста consumer;
- контролируемое удаление используемого и неиспользуемого поля provider;
- проверка идентичности consumer, provider и версии контракта в отчёте.
Исключения¶
Полный опубликованный контракт MAY использоваться вместо минимального, если provider гарантирует его целиком и проверка не превращает совместимое расширение в несовместимое изменение.
DEV-VER-011. Проверка кандидата provider¶
Уровень: MUST
Применяется к: release-кандидату provider с активными consumer contracts
До release provider должен проверить кандидат против каждого активного consumer contract для поддерживаемых версий consumer. Отчёт должен связывать проверенный release identifier или commit provider, точные версии consumer contracts и результат каждой проверки.
Неуспешная, отсутствующая, отменённая, просроченная, частично выполненная или непрочитанная проверка активного контракта не должна считаться успехом. Несовместимый результат должен блокировать release либо запускать версионированную миграцию соответствующего consumer; provider не должен изменять ожидание consumer без изменения, принятого его владельцем.
Обоснование¶
Проверка только сборки provider не доказывает сохранение фактически используемого поведения независимо поставляемых consumers.
Проверка¶
- контролируемое несовместимое изменение provider;
- тест отсутствующего, unreadable, cancelled и timed-out consumer contract;
- сверка отчёта с release identifier provider и реестром активных контрактов.
Исключения¶
Экстренное отключение уязвимого контракта выполняется по OPS-INC-003 и
должно сохранить перечень затронутых consumers и последующую проверку
поставленного состояния.
DEV-VER-012. Жизненный цикл consumer contract¶
Уровень: MUST
Применяется к: каждому consumer contract
Реестр или metadata контракта должны определять владельца consumer, статус
active или retired, поддерживаемую версию consumer, версию контракта
provider, время последней успешной проверки и проверяемый критерий удаления.
Активный контракт допускается перевести в retired только после evidence, что
ни один поддерживаемый release consumer его не использует. Просроченный либо
неподдерживаемый consumer contract не должен бессрочно блокировать provider,
но его статус нельзя удалить или изменить молча: прекращение поддержки должно
следовать опубликованному периоду миграции и критерию отсутствия использования
по BE-COMP-002 либо эквивалентному контракту используемого протокола.
Обоснование¶
Без жизненного цикла устаревшее ожидание либо навсегда блокирует provider, либо удаляется без доказательства безопасности для работающего consumer.
Проверка¶
- сверка активных контрактов с поддерживаемыми releases consumers;
- попытка удалить используемый активный контракт;
- проверка evidence и периода миграции при переходе в
retired; - поиск контракта без владельца или последней успешной проверки.
Исключения¶
Consumer contract до первого release MAY не иметь времени успешной проверки, если статус явно отличает его от активного release-gate и первая успешная проверка обязательна до release.