🚢 Релиз-процесс

Как фича доезжает от кода до прода. Сейчас - rsync-деплой из головного репо; целевое (месяц 1) - GitHub Actions → GHCR → staging → prod. Технические шаги деплоя - в runbooks/deploy.md. Правила, кто в каком репо работает параллельно - в 03 - Параллельная разработка.md.

Текущий процесс (as-is)

Фича в компонентном репо (feature/*) → PR → merge в main компонента
   → git subtree pull в головной capital → CI (тесты + сканеры) зелёный
   → security-review (если money/auth/данные) → stage-проверка
   → rsync на prod → build → alembic upgrade (one-off) → up -d → смоук

1. Разработка

Фича - в своём компонентном репо (capital-portal/capital-ledger/ capital-shared/capital-kyc), ветки feature/* / hotfix/*. Внутри сервиса - последовательно (не нарезать одну фичу на параллельные слои). shared/models + migrations/ правит один поток за раз.

2. Проверки качества (обязательно на нетривиальных изменениях)

Тесты - зелёные локально (bo + cabinet; у cabinet свой venv).
code-review (скилл) - после нетривиальной правки.
security-review - обязательно, если правка касается auth-пути, денежного пути, PII/данных клиента, партнёрской интеграции. P0/P1 → не деплоим.
Impact analysis - какие модули зависят от изменённых файлов; прогнать ВСЕ тесты, не только текущие; проверить контракты (модели ORM у каждого сервиса свои - читаешь новое поле → проверь models.py именно этого сервиса).

3. Сборка головного

git subtree pull -P <папка> <repo> main подтягивает компонент. Разошедшиеся alembic- головы сводятся merge-миграцией (alembic merge) - на проде должен быть один head.

4. Деплой

Только из головного capital, одной рукой. Шаги - runbooks/deploy.md. Порядок при новой таблице: build → one-off alembic upgrade → up -d (гоча сид-крашлупа).

5. Верификация

Реально открыть затронутые страницы авторизованным логином (зелёный healthcheck ≠ страница рендерится). Логи чисты. Не отчитываться «готово» до этого (anti-rationalization).

Миграции - expand/contract

Схема двигается совместимо: сначала совместимая миграция, потом код; деструктивные изменения - отдельным релизом позже. Перед миграцией - чекпоинт бэкапа + запись LSN (PITR ровно к «до»). Детали - runbooks/MIGRATIONS.md.

Целевой процесс (to-be, месяц 1)

git push → GitHub Actions: тесты (183+) + сканеры (gitleaks/Trivy/Dependabot/CodeQL)
  → сборка образов → GHCR
  → авто-деплой на staging (ops) → смоук
  → ручное подтверждение → prod (docker compose pull && up -d)

Rollback = откат на предыдущий образ в GHCR (храним 5 последних) - секунды.
Staging обязателен (ops-сервер, throwaway-БД): каждый релиз сначала там.
Стресс/security-тесты - только на staging (стандарт группы), не на проде.

Stage + стресс-тесты (стандарт группы)

Перед выкатом - изолированный stage (копия сервиса, throwaway-БД, без боевых данных), прогон нагрузочных/security-тестов. Для финтеха обязательно: race/идемпотентность денежных операций, IDOR/BOLA по картам/счетам, целостность ledger, OTP-replay, отказ провайдеров + graceful degradation, исчерпание пулов БД. Stage сносить после (docker compose down -v).