План развития портала качества

Цель

Портал должен давать одну проверяемую картину качества для трёх продуктовых направлений BusinessPad: BP3, CPQ и мобильного приложения. Он не хранит секреты или реальные финансовые данные и принимает только агрегированные результаты тестов.

Release gate текущей итерации

Перед следующей публикацией выполняются как одна согласованная миграция:

1. Изменения проходят Python/JavaScript tests, Ruff, строгую MkDocs-сборку и проверку publish artifact.
2. На сервере создаётся exclusive lock и устанавливается root-owned publisher protocol 2 с тем же SHA-256, что и файл в опубликованном commit.
3. Nginx проверяется на portal 404.html, доступ к public marker и запрет private dotfiles/recovery directories.
4. Сначала запускается qa_portal_preflight, затем manual publish и HTTP smoke.

Код и server-side publisher нельзя обновлять раздельно: digest attestation намеренно блокирует несовпадающие версии.

Этап 1. Поток результатов

• Назначить owner для producer /allure/runs.json и атомарной публикации Allure.
• Подключить стабильные suite: web-smoke, web-regression, api-contract, domain, mobile-smoke, mobile-regression, security, performance и ai-evaluation.
• Ввести retention и уникальный run_id, связывающий портал, pipeline, commit, версию приложения и Allure-каталог.
• Отклонять частично повреждённый индекс на стороне producer до публикации.

Готово, когда свежий запуск появляется в каталоге автоматически, ссылка на pipeline разрешена allowlist, а повторная доставка не создаёт дубль.

Этап 2. Продуктовые quality gates

Направление	Первый обязательный gate
BP3	процессы, финансы, tenant isolation, роли, идемпотентность и аудит
CPQ	конфигурация, цены, скидки, согласование, версии и итоговый документ
Мобильное приложение	Android/iOS parity, offline/retry, push/deep links и cross-client sync

Для каждого gate фиксируются owner, контур, тестовые данные, порог прохождения и ссылка на автоматизированный suite. Финансовые и tenant-isolation проверки не могут быть необязательными или скрываться общим процентом passed.

Этап 3. Усиление CI

• Зарегистрировать отдельный runner businesspad-qa-verify; deploy runner не должен выполнять произвольные verify-job.
• Собрать минимальный deploy image с Bash, OpenSSH, curl, tar и coreutils, просканировать его и закрепить digest; убрать runtime apk add из job с SSH secrets.
• Перейти от прямых pins к полному dependency lock с hashes и frozen install.
• Отключить retry устаревших rollback deployments; возврат делать новым revert commit и pipeline.

Этап 4. Публикация без окна 404

Текущий top-level rename имеет транзакционный rollback, но не является read-atomic для Nginx. Следующий архитектурный шаг — versioned release directories, проверка готового release и одно атомарное переключение current. /allure/ при этом остаётся отдельным alias и не входит в release портала.

Метрики результата

• время от завершения pipeline до появления запуска в портале;
• доля запусков с явным результатом, commit/version и рабочими ссылками;
• pass rate и длительность по suite без смешивания критичных направлений;
• количество отклонённых producer payload и причин валидации;
• возраст последнего успешного gate по каждому продуктовому направлению;
• успешность preflight/publish и число ручных recovery-событий.