Проверка изменений¶
Требования применяются к изменениям запускаемых и публикуемых компонентов.
Уровни обязательности определены в корневом README.md.
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.