Перейти к основному содержимому

Эксплуатационный release gate

Запуск и администрирование release gate CodeGraph без смешения с управляемым SDLC-закрытием. См. примеры и проверки перед применением.

Руководства

Release gate CodeGraph объединяет настроенные проверки безопасности, качества, тестов, compliance и ревью в эксплуатационное решение по выбранному проекту и профилю. Он полезен в release pipeline. Authoritative SDLC reducer хранит итоговое состояние task, story и PRD.

Перед проверкой

  1. Определите точные проект, версию и базовую Git-ревизию.
  2. Убедитесь, что CPG и входы проверок относятся к этой ревизии.
  3. Получите список профилей из установленной конфигурации.
  4. Если профиль требует оператора, используйте разрешённый operator-id.
  5. Заранее определите место для неизменяемого отчёта и связанных evidence.

Не выводите состав проверок из названия профиля: конфигурация может меняться между выпусками.

Список профилей

python -m src.cli release profiles

Команда показывает настроенные профили и текущие проверки. В документации нельзя фиксировать их количество или обещать наличие одного и того же профиля во всех установках.

Запуск проверки

python -m src.cli release check --project <project> --version <version> --base-ref <git-ref> --profile <profile> --operator-id <operator-id> --format json --language ru --output <release-gate.json>

Без --project используется unknown, поэтому в промышленной автоматизации проект следует задавать явно. Без --profile применяется профиль по умолчанию. Параметр --db позволяет выбрать существующий CPG для CLI, когда разрешения проекта недостаточно.

Решение содержит статус, проект, профиль, версию, время, число успешных и всех проверок, блокеры, предупреждения и отдельные результаты. Храните его вместе с точной ревизией исходного кода и evidence свежести.

Коды завершения CLI

Коды завершения CLI
Код Значение
0 Статус gate — pass.
1 Статус fail либо warn повышен параметром --fail-on-warn.
2 Статус warn без --fail-on-warn.

Пропущенный или недоступный входной сигнал должен быть виден в отчёте. Нулевой код подтверждает выполненный профиль; состав проверки фиксируется в отчёте.

Просмотр истории

python -m src.cli release history --project <project> --limit 20

История помогает сравнивать эксплуатационные решения. Неизменяемое хранилище evidence сохраняет связанный контекст. Перед ссылкой на старую запись проверьте проект, версию и время.

Принятие риска finding

Создание suppression — управляемое административное действие, а не техническое исправление:

python -m src.cli release suppress --finding-id <finding-id> --reason <reason> --approved-by <approver> --expires <iso-8601> --ticket <ticket> --project <project>

Просмотреть и удалить активные suppressions можно так:

python -m src.cli release suppressions list --project <project>
python -m src.cli release suppressions remove --finding-id <finding-id>

Указывайте трассируемого человеческого согласующего, ограниченную причину, срок и ticket. Suppression меняет обработку finding внутри operational gate, но не удаляет сам finding и не закрывает другую evidence lane.

Административный REST API

Аутентифицированный admin router подключён по префиксу /api/v1/admin/runtime/release-gate:

Административный REST API
Метод и маршрут Назначение
POST /api/v1/admin/runtime/release-gate/check Запустить проверку для активного контекста проекта.
GET /api/v1/admin/runtime/release-gate/profiles Получить настроенные профили.
GET /api/v1/admin/runtime/release-gate/history Прочитать историю решений.
POST /api/v1/admin/runtime/release-gate/suppress Создать согласованный suppression.
GET /api/v1/admin/runtime/release-gate/suppressions Получить активные suppressions.
DELETE /api/v1/admin/runtime/release-gate/suppressions/{finding_id} Удалить suppression.

Пример тела проверки:

{
  "profile": "standard",
  "version": "1.2.3",
  "base_ref": "origin/main"
}

Если включено создание снимков, REST-проверка также может вернуть идентификаторы снимков до и после запуска и diff. Свежесть входных evidence проверяйте по их ревизиям, временным меткам и источникам.

Operational gate и authoritative SDLC

Эти решения отвечают на разные вопросы:

Operational gate и authoritative SDLC
Решение Проверяемый вопрос
operational gate Прошёл ли выбранный release profile настроенные runtime-проверки этого запуска?
authoritative SDLC Полны ли привязанные к ревизии требования, AC, тесты, evidence lanes, traceability и finance по управляемому reducer?

Нельзя напрямую превращать успешный CLI или REST status=pass в Done для task/story/PRD. Для полного закрытия по-прежнему нужны authoritative carrier и все обязательные lanes. Release pipeline может требовать оба решения.

Восстановление

  • Если профиль неизвестен, выполните python -m src.cli release profiles и исправьте конфигурацию вызывающей стороны.
  • Если входы проекта устарели, обновите их через owning workflow и повторите ту же проверку.
  • Если warning должен блокировать CI, добавьте --fail-on-warn; не переопределяйте код 2 в downstream-скрипте.
  • Если suppression истёк или потерял обоснование, удалите его и повторите проверку.
  • Если история расходится с текущим отчётом, опирайтесь на свежий revision-bound запуск и исследуйте область старой записи.

Поддерживаемые источники

  • src/cli/governance_suite/release_gate_commands.py определяет команды CLI, параметры и коды завершения.
  • src/api/routers/query_suite/release_gate.py определяет контракты admin REST.
  • src/api/app_routers.py определяет подключённый REST-префикс.
  • src/release/ и раздел release_gate в config.yaml определяют проверки, профили, отчёты, историю и suppressions.

При расхождении авторитетны текущие исходники, конфигурация и справка CLI.