0020 — Автоматическое продвижение и тесты STAGE¶

Дата: 2026-08-23.
Статус: Частично заменено решением 0032; строгие gates сохранены только для отдельной проверки и подготовки к PROD.
Ответственный: владелец проекта.

Контекст¶

Решение 0019 определило домены и допустимый состав STAGE, но оставило открытыми триггер продвижения, обязательные тесты, автоматический deploy, откат и координацию Product/Site/Docs. Владелец подтвердил, что завершённый функционал должен попадать в STAGE автоматически и сразу после явного завершения разработки.

Фактически на дату решения существует только ветка DEV; текущий GitHub Actions workflow выполняет один CI job без deploy. Ветки STAGE/PROD, Site/Docs-репозитории, новые STAGE-домены и автоматизация deploy ещё не созданы.

Решение¶

Событие завершения¶

Точным событием завершения является разрешённый merge DEV -> STAGE.
Продвигается всё состояние выбранного commit ветки DEV. Отдельная функция не вырезается из незавершённого состояния ветки.
Любая незавершённая или заблокированная работа в DEV, входящая в candidate commit, блокирует продвижение.
Команда закрываем сессию не означает готовность к STAGE и не разрешает merge.
Merge выполняет владелец или явно уполномоченный ответственный. Агент не инициирует его из обычного завершения задачи.

Автоматический deploy¶

После реализации и явной активации pipeline разрешённый merge в STAGE является одновременно разрешением на автоматический deploy соответствующего STAGE-контура. Повторное подтверждение между merge и deploy не требуется.

До записи статуса АКТИВИРОВАНО в docs/STATUS.md действует прежняя граница: создание ветки, изменение GitHub, первый deploy, DNS и server configuration требуют отдельного разрешения. Принятие этого ADR само по себе не запускает внешние действия.

Pipeline:

проверяет pre-deploy gates;
фиксирует candidate commit, build ID и используемые image ID или другой идентификатор развертывания;
при миграции создаёт проверяемую резервную копию STAGE-БД;
разворачивает только затронутый контур;
выполняет post-deploy gates;
публикует отдельные результаты каждого gate и общий итог STAGE READY или STAGE FAILED.

Независимые gates¶

Обязательная модель:

Gate	Цель
`G1 Scope`	подтвердить acceptance criteria, документацию и отсутствие связанного блокирующего решения
`G2 Static`	проверить toolchain, границы, lint и типы без runtime
`G3 Unit`	проверить unit/component поведение и coverage
`G4 Database`	проверить integration, миграции, tenant isolation и совместимость схемы
`G5 Build`	проверить сборки web/API/worker/Storybook и отсутствие OpenAPI drift
`G6 Security`	проверить зависимости, секреты и безопасный состав конфигурации
`G7 Local E2E`	проверить пользовательские сценарии до deploy
`G8 Deploy`	проверить config, backup при миграции и запуск STAGE
`G9 Stage Smoke`	проверить health, HTTPS, API, redirects и security headers
`G10 Role E2E`	проверить `owner`, `admin`, `member`, `viewer`, `platform_admin`, `super_admin`
`G11 Cross-domain`	проверить Site → App → Docs, origin isolation и отсутствие общей cookie
`G12 Restore`	проверить восстановление в отдельном контуре при изменениях БД и по расписанию

Каждый gate получает один статус: PASS, FAIL, BLOCKED, NOT_APPLICABLE. NOT_APPLICABLE требует записанной причины. Любой обязательный FAIL или BLOCKED даёт общий результат STAGE FAILED; процентный балл не может переопределить критический gate.

Полные цели, данные, частота и критерии описаны в docs/STAGE_TESTING_STRATEGY.md.

Изоляция тестов¶

Каждый автоматический набор использует чистый checkout candidate commit, собственную временную БД или schema, отдельные порты и синтетические fixtures.
Независимость означает отдельную цель, данные, логи и результат. Post-deploy проверки естественно зависят от успешного deploy, но не объединяются с ним в один непрозрачный статус.
Постоянная STAGE-БД предназначена для ручной оценки. Автотесты не очищают и не изменяют её; для них используется отдельная временная БД либо отдельная тестовая организация с гарантированной очисткой только её данных.
Реальные клиентские и персональные данные запрещены.

Ошибка и откат¶

Ошибка до deploy не меняет STAGE.
Ошибка запуска приложения возвращает предыдущую известную рабочую версию приложения.
Ошибка post-deploy помечает candidate как STAGE FAILED; приложение автоматически возвращается к предыдущей версии только при совместимой схеме.
Миграции БД автоматически назад не выполняются.
Несовместимая или неуспешная миграция останавливает pipeline и требует контролируемого восстановления по runbook.
Volumes, dumps и данные не удаляются автоматическим откатом.

Product, Site и Docs¶

Product/STAGE обновляет lk.skuaro.top.
Site/STAGE обновляет skuaro.top.
Docs/STAGE обновляет doc.skuaro.top; developer docs независимо обновляют dev-doc.skuaro.top.
Репозитории продвигаются независимо и не запускают deploy друг друга без явной cross-repo release-записи.
Комплексный релиз фиксирует commit SHA или build ID каждого затронутого репозитория.

Merge в STAGE одного репозитория разрешает автоматический deploy только его контуров. Он не разрешает продвижение в PROD.

Последствия¶

Текущий единый CI job должен быть разделён на наблюдаемые jobs/gates.
Для активации потребуются STAGE branch protection, GitHub Environment, минимальные deploy permissions, безопасные secrets references, server runner/transport и проверенный rollback.
Первый запуск выполняется контролируемо и только после отдельного разрешения на внешние изменения.
После успешной активации обычный разрешённый merge в STAGE не требует второго ручного подтверждения deploy.

Откат или замена¶

Изменение события завершения, автоматический merge без явного решения владельца, разрешение процентной оценке скрывать критический FAIL, автоматический downgrade БД или связанный deploy независимых репозиториев требует нового ADR.