Sber, Git GitVerse
https://giga.chat/link/gcsAiHCTJz
Sberbank заимствует технологии у Законодателей мод Gooogle, Microsoft, Amazon, Apple, Meta, которые ужe поставляют программные продукты вместе с Git + CI/CD + ...
Этот тренд действительно активно набирает обороты и трансформирует то, как софт поставляется, кастомизируется и сопровождается. На практике его называют по-разному в зависимости от фокуса: GitOps, Everything-as-Code, Self-Hosted / Managed Control Plane и поставка софта через Git-репозитории как точку интеграции. Идея в том, что заказчику передают не просто «чёрный ящик» (скомпилированный бинарник или закрытый доступ в чужое SaaS), а полный репозиторий с шаблонами, инфраструктурной обвязкой и автоматизацией. Git превращается в панель управления (Single Source of Truth) для всей системы на стороне клиента. Разберём, что именно «переезжает» к пользователю в репозиторий вместе с кодом помимо обычного CI/CD.
- Инфраструктура и оркестрация (IaC / CaC) Клиент получает не инструкции «как установить», а готовые декларативные манифесты: Terraform / OpenTofu / Pulumi / Ansible — описание облачных ресурсов, виртуальных машин, сетей и хранилищ. Kubernetes-манифесты и Helm-чарты / Kustomize — полное описание контейнеров, сервисов, балансировщиков и сетевых политик. Клиент может изменить пару параметров в YAML-файле (например, размер инстанса БД), запушить в ветку — и система сама применит изменения в его контуре.
- GitOps-агенты и автоматическая синхронизация Вместо того чтобы внешний CI-сервер разработчика лез по SSH в закрытую сеть заказчика: Внутри кластера заказчика работает агент (например, ArgoCD или Flux). Агент постоянно сверяет состояние продакшена с переданным Git-репозиторием. Если вендор выпустил обновление через Pull Request или клиент изменил конфиг — агент сам подтягивает изменения в закрытый контур («pull-модель» вместо «push»).
- Базы данных и схемы данных (Migrations-as-Code) В репозиторий упаковываются не только сами таблицы, но и управление жизненным циклом данных: Скрипты миграций (Flyway, Liquibase, EF Core migrations). Сид-данные (базовые справочники, демо-датасеты). Политики резервного копирования и восстановления, описанные как пайплайны.
- Наблюдаемость и мониторинг (Observability-as-Code) Вместе с приложением клиент получает готовую инфраструктуру мониторинга: Дашборды Grafana (в виде JSON/файлов конфигурации). Правила алертов для Prometheus / VictoriaMetrics (пороги CPU, задержки запросов, отказы). Правила сбора трейсов (OpenTelemetry) и парсинга логов (Vector, FluentBit). Клиенту не нужно с нуля думать, какие метрики важны для работы сервиса — экспертиза вендора уже закодирована в репозитории.
- Безопасность и политики соответствия (Policy-as-Code) Для Enterprise-клиентов критически важно, чтобы софт соблюдал внутренние стандарты безопасности: Проверки через OPA (Open Policy Agent) или Kyverno (например: «запретить запуск от root», «не использовать внешние IP»). Шаблоны сканирования уязвимостей образов (Trivy, Grype) и зависимостей (SBOM). Клиент может адаптировать эти политики под свои стандарты ИБ прямо в Git.
- Среды разработки и документация (DevContainers / Docs-as-Code) Dev Containers: файл .devcontainer.json, позволяющий инженерам клиента открыть репозиторий в VS Code или JetBrains и получить готовую настроенную среду разработки со всеми утилитами внутри Docker-контейнера за один клик. Docs-as-Code: документация по архитектуре, API (Swagger/OpenAPI) и регламенты восстановления (Runbooks) лежат рядом с кодом в Markdown и генерируют внутренний портал знаний. Почему это стало востребовано? Суверенитет данных и безопасность (On-Premise / Private Cloud) Крупные банки, финтех, госсектор и медицина не могут просто взять публичный SaaS. Им нужен полный контроль над тем, где работают сервисы и куда текут данные. Прозрачность аудита (Audit Trail) Любое изменение конфигурации фиксируется коммитом: видно, кто автор, когда оно сделано и почему. Легко сделать откат (git revert) при сбое. Бесшовные обновления вендора Обновление продукта выглядит как git pull или слияние ветки релиза от вендора с локальной веткой клиента. Если клиент внес свои доработки, Git помогает решить конфликты стандартным merge-механизмом. Отсутствие вендор-лока Клиент уверен, что даже если компания-поставщик закроется, у него на руках остаётся вся автоматизация сборки, развёртывания и сопровождения продукта.
Вы абсолютно точно описали один из главных векторов развития современной корпоративной разработки. То, что вы перечислили, — это переход от продажи готовых программ к поставке полного жизненного цикла (Full Lifecycle-as-Code).
Сбер, запуская такие продукты, как GitVerse и GigaStudio, действительно движется в этом же направлении, адаптируя мировые практики под реалии российского Enterprise-рынка.
В контексте описанного вами тренда GigaStudio и экосистема GitVerse работают следующим образом:
- Устранение «черного ящика» через Git-репозиторий. Когда GigaStudio генерирует приложение, оно не остается внутри веб-интерфейса Сбера. Код сразу попадает в Git-репозиторий на платформе GitVerse. Пользователь получает полный контроль: он видит всю историю коммитов, может откатить изменения (
git revert), забрать репозиторий любым стандартным клиентом (git clone) и перенести его на другую платформу. Это напрямую решает проблему вендор-лока, о которой вы пишете. - Инфраструктура и оркестрация (IaC). При развертывании «в один клик» GigaStudio автоматически создает за кадром декларативные манифесты. В случае с Kubernetes-контуром (который поддерживает GitVerse On-Premise) это будут Helm-чарты и Kustomize-манифесты. Клиент получает не просто бинарник, а набор YAML-файлов, описывающих сервисы, сети и права доступа, которые можно править вручную.
- GitOps-модель синхронизации. Платформа GitVerse поддерживает агентную модель. Для Enterprise-клиентов (Self-Hosted) это означает, что в их закрытый контур ставится агент (по аналогии с Argo CD), который «тянет» (pull) изменения из корпоративного GitVerse. Внешние серверы Сбера не имеют прямого доступа внутрь сети банка, что критично для служб безопасности.
- Базы данных и миграции. В описании GitVerse указано хранение артефактов (Maven, npm, Docker) и поддержка LFS. В контексте Enterprise-поставки это означает, что в тот же репозиторий упаковываются контейнеры с базами данных и скрипты миграций (например, на базе Liquibase), обеспечивая воспроизводимость окружения.
- Наблюдаемость и безопасность (Policy-as-Code). В тарифе Enterprise платформы GitVerse заявлены «поиск секретов (Secret Scanning)», «анализ зависимостей (SCA)» и «полный Audit Log». Это прямая реализация вашего пункта о Policy-as-Code: в репозиторий зашиты правила, которые автоматически блокируют коммиты с уязвимостями или открытыми паролями, а Audit Log фиксирует каждое действие для регуляторов.
- Среды разработки (DevContainers). GigaIDE Cloud и Desktop предоставляют готовую среду. В Enterprise-контуре это реализуется через Dev Containers: инженер клиента открывает репозиторий и получает идентичное всем коллегам окружение со всеми зависимостями, исключая ситуацию «у меня на машине работает».
Как Сбер адаптирует этот тренд под российские реалии:
- Суверенитет данных. Как вы верно заметили, банки и госсектор не могут использовать публичные SaaS. Поэтому Сбер предлагает GitVerse On-Premise — установку всей платформы (Git, CI/CD, реестр пакетов, GigaStudio) внутри собственного дата-центра заказчика. При этом ИИ-слой (модели GigaCode) может работать в изолированном контуре.
- Бесшовные обновления вендора. Обновление платформы Сбера до новой версии для On-Premise клиента выглядит как слияние (merge) ветки от вендора с локально кастомизированной веткой клиента. Git выступает механизмом доставки патчей безопасности и новых функций.
- Единая точка интеграции. SberID, интеграция с корпоративными каталогами (SAML/SSO/LDAP) и зеркалами репозиториев (NPM, Maven, PyPI) внутри РФ превращают GitVerse в тот самый «Single Source of Truth» и центральный пульт управления, о котором вы говорите.
Ваша мысль о том, что Сбер заимствует подходы у глобальных технологических гигантов, верна, но с важной оговоркой: Сбер не просто копирует инструменты, а строит вокруг них «harness» (инженерную обвязку). Как отмечали спикеры на ГигаКонф, сама языковая модель — это только «двигатель». А то, как она получает контекст, как проверяются ее действия, как соблюдаются политики безопасности и как результат превращается в готовый к эксплуатации артефакт в Git — это и есть та самая трансформация, которая превращает «вайб-кодинг» в надежный Enterprise-процесс.Вопрос
Давно напрашивалось такое слияние Готовое Решение + Git. Потому что Git - дополнение к Софтверному Продукту с точки зрения безопасности, эксплуатации и дальнейшего развития кода. И вообще в Git как - бы второй Backend только в другой плоскости - Плоскости разработки, развития, хранения, тестирования итд
Ответ
Вы очень точно подметили суть архитектурного сдвига, который сейчас происходит. Git действительно перестал быть просто «папкой с историей версий» и превратился во второй, параллельный бэкенд — Control Plane (плоскость управления).
Если классический Backend отвечает за бизнес-логику (перемещение денег, расчет корзины, показ товаров), то Git как Control Plane отвечает за логику существования и изменения самой системы.
Эту «другую плоскость» можно разложить на несколько уровней, которые работают одновременно с основным бэкендом:
1. Плоскость декларативного состояния (Single Source of Truth) В классическом бэкенде состояние системы распределено: оно в базе данных, в кэше, в файлах конфигурации на серверах. В Git-плоскости состояние системы описано декларативно в коде. Если в базе данных лежит 100 пользователей, то в Git лежит манифест, который декларирует, что их должно быть 100. При расхождении агент (GitOps-оператор) автоматически приводит реальность в соответствие с Git. Это дает детерминизм: состояние системы всегда можно восстановить из кода.
2. Плоскость контракта между вендором и заказчиком Когда решение поставляется как «черный ящик», граница ответственности размыта. Вендор говорит: «У нас все работает», заказчик говорит: «У нас отвалилось». В Git-модели граница проходит строго по коммиту.
Если сломался пайплайн сборки — это зона ответственности клиента (его CI/CD).
Если в коде приложения ошибка после обновления — это зона ответственности вендора (его Pull Request).
Если клиент сам изменил YAML-файл с настройками БД и сервис упал — это видно в git blame.
Git становится юридически значимым логом (Audit Trail) всех изменений в инфраструктуре.
3. Плоскость тестирования и квалификации (Promotion Workflow) Изменения в Git проходят через те же этапы, что и данные в бэкенде, но для самой системы:
dev-ветка — песочница, где агенты могут ломать конфигурацию без вреда для пользователей.
staging-ветка — среда, идентичная продакшену, где прогоняются синтетические тесты и сканеры уязвимостей.
main/master — эталон, из которого GitOps-агент в закрытом контуре заказчика забирает только проверенные изменения.
Это превращает эксплуатацию из ручного администрирования в конвейерную доставку инфраструктуры.
4. Плоскость безопасности и отката
В традиционном Backend откат изменения (например, неудачного алгоритма) может потребовать сложных манипуляций с бэкапами БД. В Git-плоскости откат всей инфраструктуры и приложения до любого стабильного состояния — это одна команда: git revert. Поскольку инфраструктура (IaC) и код приложения живут в одном дереве, можно атомарно откатить и версию микросервиса, и настройки сети, которые его обслуживали в тот момент.
Почему это «второй бэкенд» для Enterprise: Для крупного бизнеса (банков, промышленности) эксплуатация и безопасность стоят дороже, чем написание новой бизнес-логики. Им важно не столько то, что делает приложение, сколько то, как оно меняется, кем контролируется и как быстро его можно восстановить.
Слияние «Готовое решение + Git» превращает покупку софта из акта приобретения лицензии в акт импорта управляемого процесса. Заказчик покупает не функционал, а проверенный, аудируемый и автоматически обновляемый конвейер, где Git служит тем самым мозгом (Control Plane), который синхронизирует намерения разработчиков вендора с физической реальностью серверов заказчика.
Вопрос
Есть еще одно следствие. В процессе разработки продукта всегда необходимо разарабатывать еще не только основное , но вспомогательное Программное обеспечение - и где-то надо его хранить. Вот здесь и получается, что мы можем разрабатывать не одно Приложение, а много связанных Приложений на одной кодовой Базе, как это делает Sber - GicaCode, GigaStudio + ... И как раз и gitVerse "случайно" подвернулся.
Вы абсолютно правы. Это следствие описывает переход от модели «один продукт — один репозиторий» к модели платформенной разработки (Platform Engineering). Появление GitVerse в экосистеме Сбера — это не случайность, а стратегическая необходимость, продиктованная именно этой потребностью в единой кодовой базе для всей экосистемы.
Когда компания разрабатывает не одно приложение, а целую платформу (GigaCode, GigaStudio, GigaIDE), возникают задачи, которые невозможно решить, если инструменты живут в разных, не связанных между собой Git-репозиториях:
Синхронизация общих библиотек (Shared Kernel). У GigaStudio (генерирующего код), GigaCode (помогающего его писать) и GigaIDE (где этот код открывается) должен быть общий язык. Это модели данных, API-контракты, типы компонентов и правила валидации. Если GigaStudio сгенерирует компонент, который GigaCode не сможет правильно проанализировать, а GigaIDE — подсветить, экосистема сломается. Единая кодовая база в GitVerse позволяет хранить эти общие библиотеки в одном месте. Изменение в ядре автоматически подтягивается во все продукты через зависимости (npm, Maven, NuGet) или монорепозиторий.
Каскадные изменения и рефакторинг. Если вендор решает изменить синтаксис генерируемого кода в GigaStudio, это изменение должно быть одновременно поддержано в GigaCode (чтобы ИИ-ассистент понимал новый синтаксис) и в GigaIDE (чтобы не сломалась отладка). В едином Git-дереве это делается одним атомарным коммитом, который проходит через общий CI/CD. В разрозненных репозиториях это превратилось бы в кошмар координации версий (dependency hell).
Сквозные (Cross-cutting) фичи. Безопасность (аутентификация через SberID), аудит, сбор телеметрии, работа с LFS для больших файлов — эти механизмы нужны всем инструментам. Разрабатывать и хранить их отдельно для каждого продукта экономически бессмысленно. GitVerse выступает как внутренний маркетплейс готовых инженерных решений для собственных команд Сбера.
Управление интерфейсами (API-first). GigaStudio должен программно вызывать модели GigaCode, а GigaIDE — подключаться к агентному конвейеру GitVerse. Контракты этих API живут в том же Git. Это позволяет автоматически генерировать документацию (Docs-as-Code), SDK для разных языков и мок-серверы для тестирования, гарантируя, что бэкенд платформы и фронтенд-клиенты не разойдутся в ожиданиях.
Экономика сборки (Build Economy). Вместо того чтобы настраивать CI/CD, сканирование уязвимостей и хранение артефактов для каждого из десятка инструментов отдельно, Сбер настраивает это один раз на уровне GitVerse. GigaCode, GigaStudio и другие продукты просто подключаются к готовой фабрике пайплайнов.
Почему GitVerse «подвернулся» как нельзя кстати: Для внешней аудитории GitVerse выглядит как замена GitHub для российских разработчиков. Но для внутренних нужд Сбера это, по сути, внутренний Developer Portal и Backbone.
С точки зрения архитектуры, Сбер строит «Микро-процессорную архитектуру» (ваш термин) не только для пользовательских сервисов, но и для своих инструментов разработки. В этой архитектуре:
Шина данных — это Git (поток коммитов и веток).
Единая память (Shared State) — это реестр артефактов и манифесты IaC внутри GitVerse.
Процессоры — это сами продукты (GigaCode — «процессор» написания кода, GigaStudio — «процессор» генерации, GigaIDE — «операционная система»).
И чтобы эти процессоры могли работать с общей памятью и обмениваться данными без задержек и потерь, им нужна общая, высокопроизводительная и контролируемая шина. GitVerse и стал этой шиной, позволив Сберу разрабатывать GigaStudio не как изолированный стартап внутри корпорации, а как очередной узел в единой, самодостаточной технологической платформе.
