Перейти к основному содержимому
Версия: v2 (текущая)

Обзор on-prem PanDev Metrics

Кратко. PanDev Metrics on-prem — это self-hosted дистрибутив платформы. Поставляется как Docker Compose и Kubernetes deployment, обслуживает одну организацию на инсталляцию и поддерживает LDAP / AD для SSO. На этой странице — архитектура, выбор между on-prem и Cloud, и куда идти дальше.

Что такое on-prem в PanDev Metrics​

PanDev Metrics on-prem — тот же продукт, что и Cloud: тот же backend, тот же фронтенд, те же дашборды, тот же расчёт DORA, упакованный для развёртывания в вашей инфраструктуре. Заказчик владеет базой, контролирует сетевой периметр и обновляется в своём ритме.

On-prem отличается от Cloud в двух местах. Во-первых, on-prem обслуживает одну организацию на инсталляцию — multi-tenant разделения нет, потому что весь deployment принадлежит одному заказчику. Во-вторых, в on-prem единственный поддерживаемый SSO — LDAP / Active Directory. Cloud дополнительно поддерживает вход через Google для multi-tenant-воркспейсов.

Когда выбирать on-prem, а когда Cloud​

Выбирайте on-prem, если хотя бы одно из условий ниже относится к вам:

  • Data residency — данные о разработке, идентификаторы и метрики должны оставаться внутри вашего периметра
  • Регулируемая отрасль — финансы, медицина, оборона, госсектор с внутренними требованиями compliance
  • Корпоративный LDAP / AD — источник истины: вы хотите, чтобы PanDev Metrics аутентифицировал пользователей через тот же каталог, что и остальной стек
  • Вы уже эксплуатируете свои Kubernetes или Docker-хосты и хотите единообразия в операциях

Выбирайте Cloud (pandev-metrics.com), если нужны zero-ops, автообновления и multi-organization-воркспейсы. В остальном Cloud и on-prem дают одинаковый функционал.

Архитектура верхнего уровня​

PanDev Metrics on-prem — стек из трёх обязательных компонентов: backend, frontend, PostgreSQL. Backend отдаёт REST API на порту 8080 и actuator на порту 9090. Frontend — статический React-бандл за вашим reverse proxy. PostgreSQL хранит всё состояние на отдельной машине. Сессии и rate-limit-счётчики backend держит во внутренней памяти; Redis опционален и нужен только если потом захочется горизонтально шарить сессии между несколькими backend-инстансами.

Backend и frontend обычно делят один application-хост. PostgreSQL живёт на отдельной машине — это единственный stateful-компонент, которому полезен независимый sizing по CPU, памяти и диску.

Компоненты простыми словами​

Backend (Spring + Java 17) — мозг. Принимает события от IDE-плагинов, синхронизирует данные Git и таск-трекеров, считает DORA и IDE-метрики, отдаёт REST API для frontend и плагинов.

Frontend (React + Vite) — дашборды. Это single-page-приложение, поставляющееся как статические файлы. Общается с backend по HTTPS через ваш reverse proxy.

PostgreSQL 17 хранит всё, что должно пережить рестарт: события, сотрудников, дашборды, интеграции, посчитанные метрики, аудит. На multi-tenant-таблицах включён row-level security (RLS) — defense in depth, даже если в on-prem всего одна организация.

Redis 7 — опционально. В single-node on-prem backend сам кеширует сессии и rate-limit-счётчики в памяти. Redis подключается отдельно, если хотите вынести сессии за пределы инстанса; для одной организации он не обязателен.

Чего нет в on-prem сегодня​

Несколько фич не входят в on-prem в мае 2026 — закладываться на них не нужно:

  • Multi-tenant / multi-organization — только Cloud. В on-prem одна организация на инсталляцию.
  • SAML и OIDC не поддерживаются. Единственный SSO для on-prem — LDAP / Active Directory.
  • Air-gapped deployment не поддерживается — PanDev Metrics нужен минимальный исходящий доступ для Git, таск-трекера и интеграций IDE-плагинов.

Эти ограничения сознательные и отражают текущую продуктовую реальность. Cloud-заказчики получают multi-organization сегодня. On-prem-заказчики получают полный контроль над данными и инфраструктурой.

Дальнейшие шаги​

Связанные материалы​

Источники​