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 должен его явно объявить (это принцип наименьших привилегий прямо в конфигурации пайплайна).

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

Параметр

CI/CD Variables (старый подход)

GitLab Secrets Manager

Область видимости

Весь проект / группа

Конкретный job

Ротация

Вручную

Планируется (roadmap)

Аудит‑лог

Ограниченный

Полный

Интеграция с кодом

Разрозненная

Единая платформа

Внешняя инфраструктура

Не нужна (для GitLab Vars)

Не нужна

Но не забываем, что 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:

Файл

Что парсится

pom.xml

Прямые зависимости Maven

requirements.txt

Прямые зависимости Python

build.gradle

Прямые зависимости Gradle

build.gradle.kts

Прямые зависимости Gradle (Kotlin DSL)

Итог: команды всегда получают хотя бы базовое покрытие, даже без 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 расширена поддержка моделей:

Модель

Тип

Поддерживаемые флоу

Gemini (Google)

Проприетарная, self‑hosted

Code Review, SAST Resolution, Fix CI/CD

Devstral 2 123B

Open source

Agentic workflows

GLM-5.1-FP8

Open source

Agentic workflows

прочие модели

Open source

Offline/network‑restricted

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

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

Settings → Merge requests → Default merge request title template

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

Переменная

Содержимое

%{source_branch}

Имя source branch

%{target_branch}

Имя target branch

%{first_commit}

Тема первого коммита

%{issue_id}

ID связанного issue

%{issue_title}

Заголовок связанного issue

%{source_branch_human}

Human‑readable версия имени ветки

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

  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

Компонент

Статус в 19.0

Действие

NGINX Ingress

Заменён Envoy Gateway (по умолчанию)

Миграция или явное включение NGINX до 20.0

Bundled PostgreSQL (Bitnami)

Удалён

Перейти на external PostgreSQL

Bundled Redis (Bitnami)

Удалён

Перейти на external Redis/Valkey

Bundled MinIO

Удалён

Перейти на external object storage

Mattermost

Удалён из Linux package

Мигрировать на standalone Mattermost

Spamcheck

Удалён из package/chart

Развернуть отдельно через Docker

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 с запасом времени.