8.0 KiB
8.0 KiB
Критерии приёмки — 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-syncdeploy → 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-цели хука).