Files
orchestrator/docs/work-items/ORCH-036/03-acceptance-criteria.md

8.0 KiB
Raw Blame History

Критерии приёмки — ORCH-36: Исполняемый самодеплой (Вариант B)

Work Item: ORCH-036 Stage: analysis Автор: analyst Дата: 2026-06-06

Формат: каждый критерий — проверяемое условие PASS/FAIL. Отладка и проверки выполняются на staging-цели хука (8501); реальный прод (8500) — только после approve.


AC-1. Стадия deploy исполняет реальный деплой (не бумажный)

  • PASS: на стадии deploy (после зелёного deploy-staging) вызывается хост-хук, который реально перетегирует образ, рестартит целевой сервис и выполняет health-check; deploy_status отражает РЕАЛЬНЫЙ исход хука.
  • FAIL: deploy_status: SUCCESS пишется без фактического рестарта/health (бумажный лог).
  • Проверка: прогон на staging-цели хука; в логе хука видны retag + up -d + health-loop; exit-code хука соответствует записанному deploy_status.

AC-2. Self-репо: рестарт 8500 — внешним detached-процессом, агент себя не убивает

  • PASS: для orchestrator рестарт 8500 выполняет процесс ВНЕ контейнера агента; deployer-агент завершается штатно (exit 0), его процесс не убит рестартом контейнера.
  • FAIL: deployer синхронно делает docker compose up -d orchestrator из контейнера и/или агент падает/обрывается на середине из-за рестарта собственного контейнера.
  • Проверка: симуляция на staging-цели; убедиться, что detached-процесс переживает выход агента.

AC-3. deploy_status маппится из exit-code хука

  • PASS: exit-code хука 0 → deploy_status: SUCCESS; exit-code ≠ 0 (1/2) → deploy_status: FAILED.
  • FAIL: любой иной маппинг (например SUCCESS при exit 1).
  • Проверка: unit-тест маппинга exit-code → вердикт; интеграционный прогон с искусственным кодом возврата хука.

AC-4. Провал деплоя → откат на development

  • PASS: при deploy_status: FAILED задача откатывается deploy → development (set_issue_blocked, Plane+Telegram), как в существующей ветке БАГ-8.
  • FAIL: при FAILED задача уходит в done или зависает.
  • Проверка: существующий контракт stage_engine._handle_qg_failure_rollbacks для deployer+check_deploy_status сохранён и срабатывает.

AC-5. Ручной approve обязателен и реально тормозит прод

  • PASS: при DEPLOY_REQUIRE_MANUAL_APPROVE=true прод-хук НЕ вызывается до явного «go»; после «go» — вызывается.
  • FAIL: прод-хук дёргается без approve.
  • Проверка: прогон без «go» — целевой сервис НЕ перезапущен (нет записи рестарта в логе хука, не сменился uptime/контейнер); прогон с «go» — рестарт состоялся.

AC-6. Уведомления о каждом промоуте и откате

  • PASS: на старт/успех прод-деплоя и на откат приходят и Plane-коммент в задачу, и Telegram.
  • FAIL: хотя бы один промоут/откат прошёл «молчаливо».
  • Проверка: в Plane-задаче и в Telegram-чате присутствуют сообщения для каждого исхода.

AC-7. Build-once: в прод идёт образ, прошедший staging

  • PASS: прод-деплой использует тот же образ, что прошёл staging-гейт (retag + --no-build), без пересборки.
  • FAIL: прод-деплой пересобирает образ заново (артефакт может отличаться от протестированного).
  • Проверка: sha/тег образа прод == образ, валидированный на staging; в логе нет build.

AC-8. Staging-гейт остаётся обязательным предусловием

  • PASS: прод-деплой недостижим без зелёного check_staging_status (staging_status: SUCCESS).
  • FAIL: прод-хук можно вызвать при FAILED/отсутствующем staging-вердикте.
  • Проверка: при staging_status: FAILED задача откатывается на development, до deploy не доходит.

AC-9. Авто-rollback восстанавливает прод (симуляция битого деплоя)

  • PASS: при симуляции битого деплоя на staging-цели health не проходит → хук авто-откатывает на предыдущий образ → сервис снова healthy; exit-code = 1 (rolled back); MTTR < 60с.
  • FAIL: сервис остаётся нерабочим после провала деплоя.
  • Проверка: искусственно сломать health, прогнать хук, убедиться в восстановлении и exit 1.

AC-10. Существующие инварианты не сломаны

  • PASS: не изменены контракты check_deploy_status / _parse_deploy_status, STAGE_TRANSITIONS, terminal-sync deploy → done, merge-gate (ORCH-43), rollback БАГ-8.
  • FAIL: любой из перечисленных контрактов изменён/сломан.
  • Проверка: существующие тесты deploy/staging/merge-gate зелёные; регресс-прогон pytest tests/.

AC-11. Условность по репо (не-self не ломается)

  • PASS: для не-self репо (enduro-trails) деплой идёт прежним ssh-путём; self-логика (detached, approve, 8500) применяется только для orchestrator.
  • FAIL: не-self репо затронуты self-специфичной логикой и ломаются.
  • Проверка: is_self_hosting_repo корректно разводит пути; тест на не-self репо.

AC-12. Флаг полного авто НЕ выключен в этой задаче

  • PASS: DEPLOY_REQUIRE_MANUAL_APPROVE остаётся true; переключение в false не делается.
  • FAIL: флаг выставлен в false в рамках задачи.
  • Проверка: дефолт конфигурации = true; в коде/.env.example нет принудительного false.

AC-13. Документация обновлена (golden source)

  • PASS: обновлены deployer.md (стадия deploy = вызов хука), INFRA.md (процедура), CHANGELOG.md; заведён ADR в 06-adr/.
  • FAIL: функционал изменён, документация — нет (Reviewer обязан вернуть REQUEST_CHANGES).
  • Проверка: диффы документации присутствуют в том же PR.

Definition of Done

Все AC-1…AC-13 в статусе PASS; pytest tests/ зелёный; артефакты pipeline на месте; прод (8500) во время разработки НЕ тронут (вся проверка — на staging-цели хука).