20 августа GitLab выпустила версию 19.3. В ней появились MCP-команды для поиска и чтения запросов на слияние, генератор агентных процессов по текстовому описанию и массовая обработка уязвимостей. GitLab Duo теперь может сама устранить конфликт или замечание проверяющего: изменить исходную ветку, создать коммит и закрыть обсуждение.
Раньше разработчик мог скопировать ответ чат-бота и решить, применять ли его. Теперь некоторые функции GitLab сами записывают изменения в ветку. Поэтому перед включением важно проверить не только качество ответа, но и права агента: какие проекты он читает, где может создавать коммиты и кто обязан одобрить результат.
Секреты во время сборки — отдельный продукт, а не новая переменная
В примечаниях к выпуску GitLab Secrets Manager описан как хранилище, где доступ задаётся для конкретной задачи с учётом окружения, ветки и защиты ветки. Создание, изменение и чтение попадают в журнал аудита. Это уменьшает риск переменной CI/CD с чрезмерно широкими правами.
Однако функция не стала обычной частью всех установок GitLab. На GitLab.com она находится в режиме ограниченной доступности для тарифов Premium и Ultimate, подключается как дополнение и расходует GitLab Credits. Для собственной установки в перечне доступности её нет. Перед миграцией нужно проверить тариф, регион, модель оплаты и способ аварийного доступа, а не просто заменить синтаксис переменных.
| Механизм | Граница доступа | Эксплуатационный вопрос |
|---|---|---|
| Переменная CI/CD | Зависит от защиты, окружения и настроек самой переменной. | Кто может увидеть значение и в какие задания оно попадёт? |
| Secrets Manager | Секрет выдаётся конкретному заданию с учётом окружения и ветки. | Как оплачиваются операции, где хранится журнал и что происходит при недоступности сервиса? |
| Внешнее хранилище | Определяется политиками отдельной системы и способом аутентификации GitLab. | Кто поддерживает интеграцию и как восстанавливается доступ? |
Secrets Manager не делает внешнее или облачное хранилище автоматически ненужным. Его преимущество — единая модель прав и аудита внутри GitLab; цена этой простоты — зависимость от доступности и тарифной модели той же платформы. Для регулируемой среды отдельно проверяются размещение данных, экспорт журналов и порядок ротации ключей.
Естественный язык создаёт определение процесса, но не отменяет проверку
Flow Creator принимает описание задачи в диалоге и возвращает готовое определение процесса в YAML для каталога AI Catalog. Он также может объяснить устройство процесса и помочь найти ошибку. Это снижает порог входа для специалиста, который знает процедуру согласования или выпуска, но не схему Flow Registry.
Результат остаётся исполняемой конфигурацией. Её следует проверять как код: какие инструменты доступны агенту, на каких ветках он действует, где требуется одобрение человека и что произойдёт при частичном сбое. Естественный язык меняет способ создания файла, но не переносит ответственность с владельца процесса.
В документации Flow Creator сказано, что агент знает компоненты, события запуска, входные данные и маршрутизацию Flow Registry и перед ответом обращается к актуальной документации. Это уменьшает риск устаревшего шаблона, но не проверяет деловой смысл процесса: агент не знает, допустимо ли выпускать платёжный сервис без второго согласования или кому разрешено читать журнал инцидента.
Безопасный способ использования — хранить созданный YAML в репозитории, проводить обычную проверку изменений и начинать с события, которое не затрагивает рабочую систему. Только после наблюдения за журналом запусков процессу можно выдавать запись в ветку, создание запроса на слияние или доступ к внешнему инструменту.
MCP сокращает число запросов, а не число решений
Новый вызов get_merge_request в документации MCP принимает адрес запроса на слияние и может вернуть изменения, коммиты, заметки, конвейеры или обсуждения. list_merge_requests ищет по автору, исполнителю, проверяющему, состоянию, меткам и тексту. Агенту больше не нужно собирать базовый контекст длинной цепочкой вызовов.
Документация уточняет важную деталь: связанные данные выбираются параметром include, причём за один вызов возвращается один вид данных. Значит, обещание «всё одним запросом» на странице обзора не следует понимать буквально для любого сценария. Инструмент уменьшает трение, но глубокая проверка всё равно требует нескольких обращений и оценки человеком.
У MCP есть и административная сторона. В 19.3 владелец собственной установки может запретить динамическую регистрацию OAuth-приложений, а общий клиент — заранее зарегистрировать с областью mcp. В имени динамически созданного приложения GitLab теперь показывает пользователя, который его разрешил. Эти изменения менее заметны, чем новый инструмент поиска, но именно они помогают ответить на вопрос, какой агент получил доступ к проекту.
Доступность инструментов чтения запросов на слияние шире, чем у большинства агентных функций релиза: GitLab указывает Free, Premium и Ultimate, а также GitLab.com, Self-Managed и Dedicated. Это делает MCP удобной первой точкой испытания — агент можно ограничить чтением, не разрешая ему менять ветку или закрывать обсуждение.
Массовое исправление уязвимостей меняет очередь риска
В отчёте об уязвимостях теперь можно выбрать несколько результатов SAST, запустить выявление ложных срабатываний и подготовку исправлений для оставшихся проблем. Для старого списка находок это полезнее, чем разбирать каждую запись отдельно.
Массовость повышает цену неверной классификации. Команде нужны правила приоритета, проверка созданных изменений и отдельный путь для спорных находок. Автоматическое закрытие очереди не равно уменьшению риска, если исправление ломает поведение или агент ошибочно считает уязвимость ложной.
Подробная документация Agentic SAST Vulnerability Resolution устанавливает более узкие рамки, чем обзор релиза: массовая обработка имеет статус бета-версии, управляется отключённым по умолчанию флагом и доступна для GitLab.com и Self-Managed. Запускать или отменять её могут Security Manager, Maintainer, Owner либо специальная роль с правом admin_vulnerability.
Находки идут от критической и высокой тяжести к средней, низкой, неизвестной и информационной. Для большой очереди порядок разумен, но тяжесть сканера не равна приоритету бизнеса. Уязвимость среднего уровня во внешнем платёжном пути может требовать более быстрого решения, чем критическая находка в недоступном экспериментальном модуле.
Duo уже не только советует — она меняет ветку
В 19.3 функции разрешения конфликтов и обсуждений проверки кода получили статус общей доступности для Premium и Ultimate. GitLab Duo читает конфликт или комментарий, изменяет исходную ветку, фиксирует изменение и публикует объяснение. В случае замечания она также закрывает ветку обсуждения, хотя проверяющий может открыть её снова.
Это меняет границу доверия. Подсказка в чате исчезает, если разработчик её не принимает; изменение агента уже становится частью истории ветки. Защита должна опираться на правила слияния: обязательный конвейер, владельцев кода, запрет прямого выпуска и возможность увидеть полный набор изменений до принятия.
Для команды полезен простой показатель: не сколько конфликтов агент закрыл, а сколько его изменений прошли проверку без повторного открытия обсуждения и ручного исправления. Эта доля показывает качество автоматизации лучше, чем число созданных записей в истории ветки.
Обновление стоит начинать с карты прав
Практическая проверка 19.3 начинается на копии одного проекта. Команда выбирает типовой запрос на слияние, один процесс и несколько подтверждённых уязвимостей; затем фиксирует, какие данные прочитал агент, какие изменения предложил, сколько обращений к модели потребовалось и на каком шаге вмешался человек.
- Сначала подключить MCP только для чтения и проверить журналы OAuth-доступа.
- С помощью Flow Creator создать один процесс без записи в рабочую ветку и проверить его YAML вручную.
- Передать массовому исправлению небольшой набор уже разобранных SAST-находок и сравнить решения с известным результатом.
- Только после этого разрешить Duo фиксировать изменения, сохранив обязательную человеческую проверку и правила слияния.
Если такой опыт подтверждает пользу, следующий этап — воспроизводимое внедрение: ограниченные роли, расходы по пользователям, журнал действий, обязательные проверки и порядок отката. GitLab 19.3 делает агента ближе к исходному коду и секретам. Именно поэтому главным документом проекта становится не приглашение попробовать новую функцию, а перечень того, чего агенту делать нельзя.