Релиз GitLab 19.0: ИИ-оркестрация, которая наконец-то догнала темп написания кода

21 мая 2026 года вышел мажорный релиз, переосмысляющий то, как платформа управляет жизненным циклом от идеи до деплоя.

Основной повесткой как уже принято стал ИИ, в Gitlab уделили этому особое внимание.
ИИ уже генерирует больше кода, чем успевают проверять инженеры. Merge Request’ы накапливаются, конфликты разрастаются, секреты утекают в переменные окружения, а зависимости с уязвимостями тихо живут в requirements.txt. GitLab 19.0 отвечает на этот вызов не просто набором фич, а сменой парадигмы: платформа берёт на себя операционную работу, оставляя командам только решения, требующие человеческого суждения.

Ниже я разберу релиз подробно, постараюсь описать примеры конфигурации, архитектурные схемы и дам выводы, таким образом как я это понял)

---

Проблема, которую решает фича

Традиционная проблема CI/CD: секреты хранятся либо в переменных окружения проекта (видны всем, кто имеет доступ к настройкам), либо во внешних Vault-решениях (требуют отдельной инфраструктуры, токенов, сетевой доступности). Разработчики в итоге кладут API_KEY=... прямо в .gitlab-ci.yml, а потом удивляются утечкам.

Что появилось в 19.0

GitLab Secrets Manager перешёл из закрытой беты в открытую для всех клиентов Premium и Ultimate на GitLab.com и Self-Managed. Ключевая архитектурная идея — секреты скопированы к проекту или группе и доступны только тому pipeline-job, который их явно запрашивает.

# .gitlab-ci.yml — запрос секрета через нативный механизм
deploy:
  stage: deploy
  secrets:
    DATABASE_PASSWORD:
      vault: production/db/password@ops  # путь в GitLab Secrets Manager
  script:
    - ./deploy.sh

В отличие от обычных CI/CD-переменных, секрет не «прилетает» автоматически во все jobs. Job должен его явно объявить (это принцип наименьших привилегий прямо в конфигурации пайплайна) .

Сравнение с предыдущим подходом

Но не забываем, что Secrets Manager находится в статусе Beta и не рекомендован для production согласно политике поддержки beta-функций. (но я думаю Вы это и без меня понимаете)

---

Было / Стало

Раньше Duo Developer умел генерировать код по issue. Теперь он ведёт MR от первого коммита до мержа автономно.

Новые триггеры

В 19.0 добавлены три способа активации:

1. Назначить Duo Developer исполнителем issue (@assign)

2. Нажать кнопку “Generate MR” в интерфейсе issue

3. @mention в любом треде обсуждения MR или issue

При наличии AGENTS.md и agent-config.yml в репозитории агент прогоняет тесты и проверки перед коммитом. Это критично: агент верифицирует качество кода по Вашим же правилам.

# agent-config.yml — пример конфигурации агента
agent:
  pre_commit_checks:
    - run: pytest tests/unit/
    - run: ruff check .
    - run: mypy src/
  max_iterations: 5
  auto_merge: false  # требовать ручного approve перед мержем

Разрешение конфликтов слияния (Beta)

Отдельная, но связанная фича: Duo теперь умеет автономно разрешать merge conflicts. Алгоритм:

1. Анализирует конфликтующие файлы
2. Редактирует их с учётом контекста обеих веток
3. Создаёт коммит в source branch
4. Публикует комментарий-summary для ревьюеров

Страница: Merge Request → Conflicts → "Resolve with Duo"

Или: виджет MR → кнопка "Resolve conflicts"

Важная оговорка: Duo не делает force-push на protected branches , т.е. правила защиты веток соблюдаются строго.

Фича за feature flag mr_ai_resolve_conflicts, по умолчанию отключена.

---

Проблема масштабирования

В организациях с сотнями проектов команды дублировали файл .gitlab/duo/mr-review-instructions.yaml в каждом проекте. При изменении стандартов приходилось обновлять сотни репозиториев.

Решение: иерархия инструкций

Теперь можно определить инструкции на уровне группы — они автоматически применяются ко всем проектам и подгруппам, объединяясь с инструкциями конкретного проекта.

my-org (group)
├── .gitlab/duo/mr-review-instructions.yaml  ← групповые правила
├── frontend (subgroup)
│   └── my-app (project)
│       └── .gitlab/duo/mr-review-instructions.yaml  ← + проектные правила
└── backend (subgroup)
    └── api-service (project)
        # берёт только групповые правила, если нет своих

# Групповой .gitlab/duo/mr-review-instructions.yaml
instructions:
  - "Проверяй наличие unit-тестов для каждого нового публичного метода"
  - "Убедись, что нет хардкода секретов или токенов"
  - "Комментарии на английском языке в соответствии с нашим Style Guide"
  - "Проверяй обратную совместимость публичных API"

Итоговый набор инструкций при ревью = группа + проект. Конфликтов нет — правила аддитивны.

---

Что такое SBOM-подход и зачем он лучше

Классический dependency scanner анализирует requirements.txt или pom.xml , то есть только прямые зависимости. Уязвимость в транзитивной зависимости (зависимость вашей зависимости) остаётся невидимой.

SBOM (Software Bill of Materials) — это полный граф зависимостей, включая транзитивные. GitLab теперь строит его автоматически для Maven, Gradle и Python.

Ваш проект
├── requests 2.28.0          ← прямая зависимость
│   ├── urllib3 1.26.x        ← транзитивная (CVE-2023-43804!)
│   └── certifi 2022.12.7     ← транзитивная
└── django 4.2.0
    └── sqlparse 0.4.3        ← транзитивная (CVE-2023-30608!)

Старый scanner видел только первый уровень. SBOM-scanner видит весь граф.

Автоматическое разрешение зависимостей

Если lockfile или граф зависимостей отсутствует, анализатор сам вызывает соответствующий инструментарий:
# Минимальная конфигурация — v2 template делает всё сам
include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml
variables:
  DS_VERSION: 2  # включаем v2 template с автоматическим разрешением

Для Gradle добавлено автоматическое создание gradle.graph.txt, а раньше его нужно было генерировать вручную как часть билда.

Fallback: Manifest Scanning

Если автоматическое разрешение невозможно (нет сетевого доступа, закрытые артефакты), анализатор падает обратно на manifest scanning:

Итог: команды всегда получают хотя бы базовое покрытие, даже без lockfile.

---

Зачем это нужно платформенным командам

Представьте: вы поддерживаете 20 CI/CD-компонентов в организации. Вышла новая версия deploy-component с критическим фиксом. Какие из 150 проектов организации используют старую версию? Без этой фичи — это будет ручной поиск по всем .gitlab-ci.yml.

Что показывает новый интерфейс

На странице компонента в CI/CD Catalog теперь есть вкладка Component Usage Details:

Component: deploy-component v2.1.0
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Outdated versions (показаны первыми):
  ⚠️  my-org/service-a        v1.8.0  (latest: v2.1.0)
  ⚠️  my-org/legacy-app       v1.5.2  (latest: v2.1.0)
  ⚠️  my-org/api-gateway      v2.0.1  (latest: v2.1.0)
Up to date:
  ✅  my-org/frontend         v2.1.0
  ✅  my-org/backend          v2.1.0

Проекты с устаревшими версиями отображаются первыми, что позволяет приоритизировать обращения к командам, использующим старые версии с известными уязвимостями.

---

Переход Duo Core на usage-based billing

С GitLab 19.0 модель оплаты Duo Core изменилась: Code Suggestions в Web IDE и desktop IDE теперь потребляют GitLab Credits. Это означает переход от seat-based к потреблению по факту использования.
Одновременно Duo Chat стал агентным: теперь он работает поверх GitLab Duo Agent Platform. Для активации:

Settings → General → GitLab Duo Agent Platform → Enable

(для instance: Admin → Settings → AI/ML)

Per-session approvals для агентных инструментов

Агентный Chat может использовать инструменты от вашего имени: создавать issues, запускать пайплайны, читать файлы. По умолчанию каждый вызов инструмента требует отдельного подтверждения.

Новый механизм per-session approvals позволяет одобрить конкретный инструмент на всю сессию:

Разрешить "create_issue" для этой сессии? [Разрешить один раз] [Разрешить для сессии] [Отклонить]

Администраторы контролируют поведение через каскадные настройки:

instance → group → subgroup → project

Варианты:
- "On by default"     — per-session approvals включены
- "Off by default"    — каждый вызов требует подтверждения (DEFAULT)
- "Always off"        — нельзя изменить на уровне группы/проекта

Новые модели в Agent Platform

Claude Opus 4.7 теперь доступен в GitLab Duo Agent Platform. Модель ориентирована на сложные многошаговые задачи: пайплайны CI/CD, код-ревью с анализом архитектуры, резолюция уязвимостей.

Для Self-Managed расширена поддержка моделей:

---

Шаблоны заголовков Merge Request

Одна из самых ожидаемых качественных фич: теперь можно задать шаблон заголовка MR на уровне проекта.

Settings → Merge requests → Default merge request title template

Доступные переменные:

Пример шаблона:

  Resolve %{issue_id} "%{issue_title}"

Результат:

  Resolve 123 "Fix login bug"

Улучшенная поддержка массивов в CI/CD inputs

# Доступ к элементам массива через индекс
spec:
  inputs:
    services:
      type: array
run:
  script:
    - echo "Primary: $[[ inputs.services[0] ]]"
    - echo "Fallback: $[[ inputs.services[1] ]]"

Выбор нескольких значений в UI пайплайна

При ручном запуске пайплайна с inputs теперь можно выбрать несколько значений из дропдауна. Выбранные значения объединяются в массив: ["staging", "production"]. Практически: перезапуск сервисов на нескольких окружениях, сборка нескольких Docker-образов — всё в одном запуске.

HMAC-подписи для webhooks

Существующий механизм X-Gitlab-Token отправляет статический секрет в plain text — уязвимо к перехвату и replay-атакам.

Новый механизм: при добавлении signing token к webhook GitLab вычисляет HMAC-SHA256 подпись над:

signature = HMAC-SHA256(
  key = signing_token,
  data = webhook_id + "." + timestamp + "." + payload
)

Заголовки в запросе:
webhook-id: wh_01HXYZ...
webhook-timestamp: 1716285600
webhook-signature: v1=a3f9c2...

---

# Поиск только в конкретном репозитории
def authenticate repo:my-group/my-project

# Поиск по паттерну (несколько репозиториев)
def authenticate repo:my-group/service-*

# Комбинирование с другими фильтрами
class UserController repo:my-org/backend language:ruby

Это устраняет боль: раньше нужно было переходить в каждый проект отдельно для поиска по коду.

---

Обязательные обновления перед миграцией на 19.0

Без этих шагов upgrade невозможен:

# Порядок обновления для Linux package:
# 1. Обновить PostgreSQL 16 → 17 (если используется bundled)
sudo gitlab-ctl pg-upgrade -V 17

# 2. Проверить версию Redis
redis-cli INFO server | grep redis_version
# Нужна 7.2+ или Valkey 7.2+
# Redis 6 больше НЕ поддерживается

# 3. Проверить ОС
lsb_release -a
# Ubuntu 20.04 — НЕ поддерживается начиная с 19.0
# Нужна Ubuntu 22.04+

# 4. Только после этого:
sudo apt-get update && sudo apt-get install gitlab-ee

Изменения в Helm chart

Bundled Bitnami компоненты предназначались только для PoC и тестовых сред.

---

Для разработчиков

— Duo Developer берёт на себя рутину: создание MR по issue, разрешение конфликтов, предварительные проверки.

— Per-session approvals снижают «approval fatigue» при работе с агентным Chat.

— HMAC-подписи для webhooks — если вы интегрируете GitLab с собственными сервисами, обновите verification-логику.

Для платформенных инженеров

— Component analytics даёт полную картину использования CI/CD компонентов — больше не нужно grep по всем репозиториям.

— Group-level review instructions устраняют дублирование конфигурации.

— Настройка параллельных пайплайнов merge train позволяет балансировать нагрузку на runners.

Для security-команд

— SBOM-based dependency scanning с автоматическим разрешением закрывает слепое пятно транзитивных зависимостей.

— Secrets Manager с per-job scoping — правильная архитектура для управления секретами.

— Network access controls для Agent Platform дают governance-слой над исходящим трафиком агентов.

— Auto remediation для уязвимых зависимостей Ruby (эксперимент) — первый шаг к полностью автоматическому patch management.

Для DevOps / SRE на Self-Managed

— PostgreSQL 17 — обязательно, Redis 7.2 — обязательно, Ubuntu 22.04+ — обязательно.

— Helm chart: bundled Bitnami компоненты удалены. Это ломающее изменение для тестовых инсталляций.

— Envoy Gateway вместо NGINX — новый default. NGINX остаётся доступным до GitLab 20.0.

---

GitLab 19.0 — это релиз, в котором платформа последовательно забирает на себя операционную нагрузку: управление секретами, разрешение конфликтов, мониторинг зависимостей, Code Review по корпоративным стандартам.

Ключевая архитектурная идея версии: ИИ-агенты встроены в процессы разработки, а не добавлены сверху. Duo Developer «проходит» ваши тесты. Secrets Manager «ограничивает их видимость» до уровня job. SBOM-scanner сам «строит граф» там, где его нет.

Для Self-Managed администраторов это нагруженный релиз: несколько обязательных миграций, удаление bundled компонентов, смена default networking в Helm. Планируйте upgrade с запасом времени.