CI/CD

Зачем нужно

Документ описывает обязательный пайплайн сборки, тестирования и релизов для всех сервисов экосистемы.

Платформа

• Репозиторий: GitHub.
• CI: GitHub Actions.
• Реестр: GHCR.
• Деплой: ArgoCD (GitOps) → Kubernetes.

Ветки

• main — стабильная, защищена.
• release/* — стабилизация релиза.
• feature/*, fix/*, chore/* — рабочие ветки.
• PR в main обязателен.

Защита main

• 1+ approve от code owners.
• Все checks зелёные.
• Линейная история (rebase или squash).
• Запрет force push.

Pull Request обязательный набор checks

Check	Назначение
lint	ESLint + Prettier
typecheck	tsc --noEmit
test:unit	Vitest
test:integration	Vitest + testcontainers (postgres, redis)
test:e2e	Playwright (для frontend)
db:migrate-check	проверка, что миграции накатываются и совместимы с предыдущей версией
openapi:diff	автогенерация и проверка breaking changes
security:audit	npm audit / snyk
security:secrets	gitleaks
bundle:size	budget enforcement для frontend
docs:canonical-status	запрещает canonical: true + status: draft
docs:ddl-location	запрещает canonical CREATE TABLE вне domains/<domain>/database-schema.md; feature SQL допустим только как conceptual/non-canonical
docs:permissions-catalog	сверяет permissions из matrices/api-map/rbac/organizations с packages/permissions/catalog.ts
docs:message-terminology	запрещает новые eventType, eventId, eventVersion в canonical docs кроме backward compatibility sections
docs:oauth-schema	проверяет совместимость OAuth client DDL: public без secret и без client_credentials, confidential/service с secret, client_credentials без обязательных redirects

Сборка

• TurboRepo / nx для кеша между сервисами;
• Docker multi-stage для backend;
• Next.js standalone output для frontend;
• Образы тегируются commit sha и release version.

Версионирование

• Conventional commits (feat:, fix:, chore:, ...);
• Changesets для версий пакетов и сервисов;
• Release tag: v<major>.<minor>.<patch>.

Окружения и продвижение

local → dev → staging → prod

• dev — автодеплой каждого merge в main;
• staging — деплой на тег staging-* или ручной promotion;
• prod — деплой по тегу vX.Y.Z после approve.

Базовый workflow

1. PR → checks → review.
2. Merge в main (squash).
3. CI собирает образы, публикует в GHCR.
4. ArgoCD синхронизирует dev.
5. Smoke tests на dev.
6. Promotion на staging.
7. Релизный тег → prod.

Database migrations в продакшене

• Миграции выполняются перед старым кодом, остающимся совместимым (см. data-baseline).
• Если миграция тяжёлая — отдельный job, не блокирующий деплой.
• Никогда автоматически в prod без явного gate.

Rollback

• Rollback через ArgoCD на предыдущий tag;
• БД-rollback требует отдельной down-миграции; обычно — forward-fix через новую миграцию.

Секреты в CI

• GitHub Encrypted Secrets;
• OIDC от GitHub в Kubernetes для деплоя без long-lived credentials;
• Секреты не печатаются в логах (::add-mask::).

Релизные ноты

• Автоматически из conventional commits + Changesets;
• Публикуются вместе с тегом.

Перформанс CI

• Кеш зависимостей (pnpm store);
• Кеш TurboRepo;
• Шардинг тестов;
• target: PR check < 8 минут.

Запрещено

• Деплой в prod вручную из локальной машины.
• Skipping CI checks (--no-verify).
• Push к main без PR.
• Хранение секретов в репозитории.

Связанные документы

• tech-stack.md
• topology.md
• security-baseline.md
• data-baseline.md