GitLab 19.0, релиз которого вышел 21 мая 2026 года, расширяет роль агентного ИИ далеко за пределы автодополнения кода. Платформа добавила публичную бета-версию Secrets Manager, довела AI-сценарии в merge request почти до полного цикла и вывела в общую доступность SBOM-сканирование зависимостей. Для русскоязычных команд это важный сигнал: конкуренция между DevOps-платформами смещается от «кто лучше пишет код» к «кто лучше контролирует, что именно уезжает в прод и с какими рисками».
Главная идея релиза в том, что GitLab 19.0 пытается встроить ИИ не в одну кнопку генерации, а в рутину вокруг поставки ПО: хранение секретов, разбор замечаний ревьюеров, разрешение конфликтов, проверку цепочки поставок. Об этом сообщает InfoQ. Если раньше разговор об AI в DevTools почти всегда упирался в code completion, то теперь GitLab продает другую логику: ускорять надо не только написание строк, но и весь процесс, где эти строки превращаются в поставляемый, проверяемый и формально одобренный релиз.
Самое заметное нововведение для security-команд и platform engineering — GitLab Secrets Manager, который вышел в публичную бету для пользователей Premium и Ultimate. Секреты теперь можно хранить прямо в той же платформе, где живут репозитории и CI/CD-пайплайны, а доступ к ним ограничивается только теми job, которым он действительно разрешен. GitLab не строит для этого отдельную модель авторизации: контроль доступа и аудит завязаны на уже существующую иерархию групп и проектов. Практический смысл прост: если учетные данные утекли или были скомпрометированы, команда может отследить по журналу аудита, какие job их использовали. При этом GitLab не пытается заменить специализированные хранилища, а интегрируется с HashiCorp Vault, AWS Secrets Manager, Azure Key Vault и Google Cloud Secret Manager. Для крупных компаний это важнее любого маркетингового тезиса про «единую платформу»: миграция без насильственного отказа от уже внедренных секрет-хранилищ обычно продается лучше, чем очередной призыв все переписать с нуля.
Вторая большая зона изменений — merge request. GitLab расширил Developer Flow так, чтобы агент работал не только на этапе подготовки кода, но и по всей цепочке MR. Теперь он может разбирать комментарии ревьюера, предлагать разбиение слишком больших merge request на более мелкие, а также помогать с конфликтами. Отдельно GitLab подчеркивает, что перед коммитом агент читает файл AGENTS.md с правилами проекта, чтобы учитывать контекст команды, а не действовать по абстрактным настройкам «по умолчанию». Это важная деталь: именно отсутствие проектного контекста часто делает AI-инструменты шумными и опасными в реальной разработке.
Для конфликтов GitLab добавил кнопку Resolve with Duo в бета-режиме. Сценарий такой: система анализирует обе ветки, делает коммит с предлагаемым исправлением и оставляет комментарий с кратким резюме для следующего ревьюера. Есть и one-click rebase-and-merge с поддержкой fast-forward и semi-linear merge. Отдельно GitLab оговаривает, что Duo уважает правила branch protection и не делает force-push в защищенные ветки. Для команд, которые уже устали объяснять менеджменту разницу между «ускорением» и «сломали политику репозитория ради удобства демо», это, пожалуй, одна из самых существенных частей релиза.
ИИ начинает считать деньги
Вокруг GitLab Duo меняется не только функциональность, но и экономика использования. В GitLab 19.0 базовый пакет Duo Core переведен на usage-based billing. Подсказки кода в Web IDE и настольных IDE теперь потребляют GitLab Credits. А GitLab Duo Chat становится агентным и работает на GitLab Duo Agent Platform, которую командам нужно включить, если они хотят продолжать пользоваться чатом. На языке закупок и бюджетирования это означает неприятную, но честную вещь: AI-функции окончательно перестают быть «бесплатным бонусом к лицензии» и превращаются в отдельную статью расходов с измеримым потреблением. Для IT-директоров и владельцев платформ это, вероятно, не менее важный релизный пункт, чем сами новые кнопки. Когда вендор переводит ИИ на кредиты и usage-модель, обсуждение почти сразу уходит от демонстрации возможностей к unit-экономике: сколько стоит один ускоренный merge request, одна подсказка в IDE и один сокращенный цикл ревью.
Для platform engineering GitLab добавил Components Analytics — аналитику по компонентам CI/CD Catalog. Она показывает, какие именно компоненты и версии используются по всей организации и где еще не раскатились security-фиксы. На бумаге функция выглядит как «еще один дашборд», но для больших инсталляций это попытка закрыть старую боль: компании часто стандартизируют CI-компоненты, а потом теряют видимость того, кто и на чем реально сидит. В результате патч уже есть, а у половины команд по-прежнему живет старая сборочная логика, о которой вспоминают только после инцидента.
Ставка на supply chain и on-prem
Третья ключевая часть релиза — безопасность цепочки поставок. SBOM-based dependency scanner стал общедоступным и охватывает экосистемы Maven, npm, NuGet, PyPI, Go и Cargo. GitLab также по умолчанию включает automatic dependency resolution для Maven, Gradle и Python: если проект не закоммитил lockfile или экспорт графа зависимостей, система сама попробует сгенерировать нужные артефакты, а при необходимости откатится к manifest scanning. Для DevSecOps-практики это вполне прагматичный шаг. Большая часть проблем с анализом зависимостей в реальной жизни не в том, что сканера нет, а в том, что репозиторий оформлен «почти правильно», но недостаточно, чтобы инструмент увидел полную картину. Если платформа берет часть этой грязной работы на себя, сигнал в отчетах становится полезнее.
Сюда же ложатся security configuration profiles: команды могут включать Secret Detection, SAST и dependency scanning через политики, а не через ручные правки CI-конфигурации в каждом проекте. Это снова про контроль на уровне платформы, а не про героизм отдельных репозиториев. Для self-hosted-среды GitLab расширил Duo Agent Platform поддержкой четырех open-source моделей, включая Mistral Devstral 2 123B и GLM-5.1, а также добавил поддержку Claude Opus 4.7 и Gemini. С учетом интереса крупных компаний к air-gapped окружениям здесь считывается понятный посыл: вендор хочет остаться релевантным не только для облачных команд, но и для тех, кто по регуляторным или внутренним причинам не готов отправлять чувствительный контекст наружу.
У релиза есть и менее гламурная сторона: GitLab поднимает минимальные требования платформы. Минимальной версией PostgreSQL становится 17, поддержка Redis 6 заканчивается, а Linux-пакеты для Ubuntu 20.04 и SUSE больше не выпускаются. Это не headline для маркетинга, но именно такие пункты часто определяют реальную стоимость апгрейда. В среде, где обновление DevOps-платформы тянет за собой базу, кеш, runner-инфраструктуру и внутренние шаблоны автоматизации, «новые AI-фичи» почти всегда приходят в комплекте с инвентаризацией технического долга.
GitLab явно играет в ту же гонку, что и GitHub с Atlassian: агентный ИИ уже продают не как автора кода, а как оператора процессов вокруг кода. Вопрос для рынка теперь не в том, у кого агент звучит умнее на сцене, а в том, кто убедительнее свяжет скорость, управление доступами, аудит и цену использования в один рабочий контур. Исходный материал и цитаты по релизу можно посмотреть в .