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