Перейти к содержанию

Стратегия тестирования STAGE

Статус: ОТДЕЛЬНЫЙ СТРОГИЙ КОНТУР; НЕ ЗАПУСКАЕТСЯ ПО УМОЛЧАНИЮ

Обновлено: 2026-08-23.

Цель

По решению 0032 обычная разработка сразу размещается на STAGE после минимальной сборки/запуска и проверяется владельцем в браузере. Gates G1–G12 ниже запускаются только командой ПРОВЕРИТЬ, перед PROD или отдельным прямым указанием владельца. Они не блокируют быстрые UI/UX-итерации и не требуют commit/hash/merge candidate.

При этом STAGE не является демо- или mock-режимом: по решению 0034 регистрация, email/Auth, sessions, permissions и Product-функции работают тем же штатным путём, что и будущий PROD. Среды различаются данными и инфраструктурой, а не поведением.

Дать владельцу проверяемый ответ на два разных вопроса:

  1. можно ли безопасно развернуть candidate в STAGE;
  2. готов ли развёрнутый STAGE к ручной оценке.

Успешный STAGE не означает готовность к PROD.

Итоговые состояния

Состояние Значение
STAGE NOT DEPLOYED pre-deploy gate остановил продвижение; работающий STAGE не изменён
STAGE READY все обязательные pre- и post-deploy gates прошли
STAGE FAILED deploy или обязательная post-deploy проверка не прошли
STAGE BLOCKED проверку нельзя выполнить из-за отсутствующей среды, доступа или внешней зависимости

Каждый gate возвращает PASS, FAIL, BLOCKED или NOT_APPLICABLE. Для NOT_APPLICABLE обязательны причина и ответственный. Усреднённый процент не используется как условие допуска.

Pre-deploy gates

G1 Scope

  • Цель: доказать, что весь candidate завершён и может оцениваться как единое состояние.
  • Вход: promotion PR DEV -> STAGE, acceptance criteria и перечень затронутых контуров.
  • PASS: criteria закрыты; user/developer docs обновлены по необходимости; нет связанного ОТЛОЖЕНО, failed check или незавершённой работы.
  • FAIL: состав не определён, присутствует незавершённая работа или обязательная документация отсутствует.

G2 Static

  • Цель: обнаружить структурные и типовые дефекты без запуска продукта.
  • Проверки: npm run toolchain:check, npm run boundaries:check, npm run lint, npm run typecheck.
  • PASS: каждая команда завершилась кодом 0.

G3 Unit

  • Цель: проверить изолированную бизнес- и UI-логику.
  • Проверки: npm run test:coverage.
  • PASS: все тесты прошли, принятые coverage thresholds не снижены.

G4 Database

  • Цель: доказать корректность PostgreSQL, миграций и изоляции данных.
  • Данные: новая временная БД и отдельный upgrade-сценарий от предыдущей поддерживаемой схемы.
  • Проверки: integration lifecycle, повторяемость миграции, tenant isolation, session revoke, concurrency для затронутых операций.
  • PASS: все обязательные сценарии прошли; постоянная STAGE-БД не использовалась тестами.

G5 Build

  • Цель: доказать воспроизводимость поставляемых частей.
  • Проверки: npm run build, npm run build:storybook, npm run openapi:verify.
  • PASS: сборки успешны, generated diff отсутствует, candidate commit/build ID записаны.

G6 Security

  • Цель: исключить известные критические риски до deploy.
  • Проверки: production dependency audit, secret scan без вывода значений, проверка runtime variables и запрещённых файлов/данных.
  • PASS: нет critical/high production advisory, секретов в candidate и реальных данных.
  • BLOCKED: advisory или подозрение на секрет требует отдельного решения и останавливает продвижение.

G7 Local E2E

  • Цель: проверить ключевые пользовательские сценарии до изменения STAGE.
  • Проверки: npm run test:e2e; визуальные проверки выполняются в принятом baseline-окружении.
  • PASS: обязательные Auth, access, Today, Admin и затронутые сценарии прошли.

Deploy gate

G8 Deploy

  • Цель: безопасно изменить только выбранный STAGE-контур.
  • До изменения: проверить точный commit/build ID, конфигурацию, свободные ресурсы и предыдущую рабочую версию.
  • При миграции: создать dump и проверить его чтение до запуска migration job.
  • PASS: migration job при необходимости завершён успешно, сервисы запущены, предыдущая версия и recovery path сохранены.
  • FAIL: STAGE возвращается к прежнему приложению, если это безопасно; schema downgrade автоматически не выполняется.

Post-deploy gates

G9 Stage Smoke

  • Цель: доказать базовую эксплуатационную работоспособность.
  • Проверки: liveness/readiness, HTTPS, redirects, same-origin API, security headers, отсутствие restart loop и новых error/fatal logs.
  • PASS: все обязательные endpoints и сервисы здоровы.

G10 Role E2E

  • Цель: проверить фактическую матрицу доступа.
  • Роли: только реализованные из owner, admin, member, viewer, platform_admin, super_admin.
  • Проверки: разрешённые действия доступны, запрещённые дают 401/403, tenant data не раскрываются.
  • Нереализованная роль получает NOT_APPLICABLE с ссылкой на status/decision, а не ложный PASS.

G11 Cross-domain

  • Цель: проверить связанность и изоляцию STAGE-экосистемы.
  • Проверки: skuaro.top -> lk.skuaro.top -> doc.skuaro.top, публичный доступ без Basic Auth, noindex, корректные ссылки, отсутствие общей domain cookie и доступа Site/Docs к данным App.
  • PASS: переходы работают, каждый origin применяет собственную модель доступа.

G12 Restore

  • Цель: доказать возможность восстановления, а не только наличие dump.
  • Контур: отдельная временная БД без изменения постоянной STAGE-БД.
  • Обязательно: при изменении схемы/миграций и перед PROD promotion.
  • Планово: по ночному или согласованному расписанию после включения backup policy.
  • PASS: dump восстановлен, schema/data checks и минимальный API smoke прошли.

Изоляция и данные

  • Каждый pre-deploy job использует чистый checkout candidate commit.
  • Тестовые БД, schemas, ports и fixtures не переиспользуются между независимыми jobs.
  • Persistent STAGE evaluation data не очищаются автоматическими тестами.
  • Cleanup ограничивается ресурсами конкретного test run; production/STAGE volumes не удаляются.
  • Все fixtures синтетические и не содержат реальных email, клиентов, платежей или переписки.

Отчёт

Для каждого продвижения сохраняются:

  • candidate commit и затронутые репозитории/контуры;
  • версия toolchain и время запуска;
  • статус и длительность каждого gate;
  • ссылка на логи и test artifacts без секретов;
  • migration/backup/restore status;
  • итог STAGE READY, STAGE FAILED, STAGE BLOCKED или STAGE NOT DEPLOYED;
  • предыдущая и текущая версии STAGE;
  • ответственный за явный merge.

Текущее ограничение

На 2026-08-23 стратегия не автоматизирована: существует только DEV, Site/Docs-репозитории не созданы, новые STAGE-домены не развёрнуты, а .github/workflows/ci.yml содержит один quality job без deploy.