Статья также доступна на украинском (перейти к просмотру).

Содержание :

• Что главное в GitLab 19.0

• Сравнение с предыдущими релизами

• GitLab Duo: шаг к Agentic AI

• GitLab Secrets Manager

• Безопасность: сканирование зависимостей и SBOM

• GitLab CI/CD и GitLab Runner 19.0

• Несовместимые изменения для собственных инсталляций GitLab

• План обновления GitLab

21 мая 2026 года вышел релиз GitLab 19.0. Версия усиливает DevOps-платформу по нескольким направлениям: GitLab Duo и GitLab AI, встроенное управление секретами, сканирование безопасности на основе SBOM, GitLab Runner 19.0 и новые требования для собственных инсталляций GitLab.

Если команда использует GitLab на своем сервере, обновление GitLab лучше проверить заранее. 

Что главное в GitLab 19.0

GitLab 19.0 продолжает курс предыдущих выпусков, но делает его более практичным. AI-функции ближе к реальным задачам: задачам, запросам на слияние, проверке кода, конвейерам CI/CD и исправлению конфликтов. Для собственных инсталляций GitLab также важны PostgreSQL 17, Redis 7.2, исполнители задач и Kubernetes-схема.

Если коротко, релиз GitLab 19.0 следует оценивать по следующим направлениям:

• GitLab Duo переходит от подсказок к агентным действиям в рабочем процессе.

• GitLab Secrets Manager добавляет встроенное управление секретами для конвейеров.

• Сканирование зависимостей использует SBOM, чтобы лучше видеть компоненты проекта.

• GitLab CI/CD получает более удобные входные параметры и сценарии из CI_JOB_TOKEN.

• Собственные установки GitLab требуют внимательной проверки инфраструктуры перед обновлением.

То есть этот выпуск одинаково важен для разработчиков, DevOps-инженеров и администраторов. Первые получают больше автоматизации в запросах на слияние, вторые, более гибкий конвейер CI/CD, а третьи, четкий список компонентов, которые нужно обновить до перехода на новую версию.

Сравнение с предыдущими релизами

По сравнению с GitLab 17.9, где главным акцентом был GitLab Duo Self-Hosted, GitLab 19.0 переносит AI ближе к ежедневному рабочему процессу. GitLab Duo теперь работает не только как подсказочный помощник, а как инструмент для проверки кода, создания запросов на слияние и разрешение конфликтов.

По сравнению с GitLab 18.11, где профили настройки безопасности уже охватывали SAST и обнаружение секретов, новая версия добавляет сканирование зависимостей и SBOM-подход. Для администраторов разница еще более заметна: PostgreSQL 17, Redis 7.2, изменения в Helm и отказ от Ubuntu 20.04 влияют на сам план обновления.

В предыдущих релизах многие новинки можно внедрять постепенно, не меняя базовую инфраструктуру. В GitLab 19.0 часть решений уже привязана к новым минимальным требованиям. Поэтому сравнение с предыдущими релизами показывает две линии развития: больше AI и безопасности для пользователей, но более тщательная подготовка для администраторов.

GitLab Duo: шаг к Agentic AI

Главная тема GitLab 19.0 — это GitLab Duo  Платформа движется к Agentic AI, когда агент в рамках разрешений анализирует задачу, готовит изменения, запускает проверки и возвращает краткий результат. Это оркестрация AI: автоматизация разработки работает внутри процесса.

Групповые правила для проверки кода

GitLab Duo теперь поддерживает групповые инструкции по проверке кода. Раньше правила приходилось дублировать в каждом репозитории, а теперь можно задать их на уровне группы или подгруппы. Это удобно для инфраструктурных команд, поддерживающих многие сервисы и желающих единые стандарты проверки кода.

.gitlab/duo/mr-review-instructions.yaml
review:
  focus:
    - security
    - maintainability
    - tests

GitLab Duo Developer можно назначить на задачу, упомянуть в обсуждении или использовать для создания запроса на слияние. В бета-режиме он также помогает с конфликтами слияний: анализирует конфликт, редактирует файлы, создает комит и добавляет пояснения в запрос на слияние.

GitLab Duo Agent Platform получила Claude Opus 4.7, самостоятельно развернутый Gemini и дополнительные модели с открытым кодом. Для изолированных сред это важно: GitLab AI можно запускать ближе к собственной инфраструктуре и внутренним политикам безопасности.

Практическая польза GitLab Duo наиболее заметна в больших командах. Когда в группе десятки репозиториев, равные правила проверки кода, шаблоны запросов на слияние и требования к тестам часто разъезжаются. Групповые инструкции помогают держать единый стиль без копирования файлов между проектами.

GitLab Secrets Manager

GitLab Secrets Manager в GitLab 19.0 перешел в открытую бета-версию для Premium и Ultimate. Это встроенный механизм хранения и использования секретов в GitLab CI/CD без обязательного подключения внешних хранилищ типа HashiCorp Vault или AWS Secrets Manager.

Секреты можно привязывать к проекту или группе, а доступ получают только те задачи, которые явно его запрашивают. Такая модель уменьшает риск утечки из-за переменной среды или журнала конвейера. В перспективе GitLab Secrets Manager может стать основой управления секретами, журнала аудита и единых правил доступа.

deploy:
  stage: deploy
  secrets:
    PROD_TOKEN:
      gitlab_secrets_manager:
        name: production/api-token
  script:
    - ./deploy.sh

Из-за статуса бета-версии начинать лучше с тестовых проектов, отдельной политики доступа и резервного плана.

Для небольших команд это способ снизить количество сторонних сервисов. Для крупных компаний удобна основа для единой политики доступа между группами, проектами и средами. Особенно полезным GitLab Secrets Manager будет там, где секреты часто используются при развертывании, интеграционных тестах и ??служебных задачах.

Безопасность: сканирование зависимостей и SBOM

В блоке безопасности релиз GitLab 19.0 делает упор на сканировании зависимостей на основе SBOM. SBOM или перечень компонентов программного обеспечения описывает состав приложения и помогает видеть не только прямые, но и транзитивные зависимости. Именно из-за них часто появляются уязвимости зависимостей.

Новое сканирование зависимостей на основе SBOM стало общедоступным для Ultimate. Maven, Gradle и Python-проекты могут автоматически получать более полный граф зависимостей. Если граф построить невозможно, анализатор переходит в сканирование файлов манифеста и все равно дает базовое покрытие.

Для DevSecOps это важное улучшение: сканирование безопасности становится более точным. Также появилась экспериментальная автоматическая поправка для Ruby-проектов, когда GitLab готовит запрос на слияние с более безопасной версией пакета.

В предыдущих версиях команды чаще видели проблему уже после сканирования или ручной проверки зависимостей. В GitLab 19.0 SBOM становится частью регулярного контроля. Это помогает быстрее реагировать на новые CVE, оценивать влияние пакета на продукт и объяснять риски не только разработчикам, но и специалистам по безопасности.

GitLab CI/CD и GitLab Runner 19.0

У GitLab 19.0 появилась новая возможность для CI_JOB_TOKEN:  его можно использовать не только для доступа к ресурсам, но и для передачи изменений в другой проект, если целевой проект это позволяет, а пользователь, запустивший pipeline, имеет необходимые права. Это может снизить потребность в персональных или проектных токенах для части служебных CI/CD-сценариев. 

Улучшены и входные параметры конвейера CI/CD. Конвейер может принимать массивы, а при ручном запуске можно выбрать несколько значений. Это удобно, когда один сценарий работает с несколькими средами или сервисами.

spec:
  inputs:
    environments:
      type: array
deploy:
  script:
    - echo "$[[ inputs.environments[0] ]]"
    - echo "$[[ inputs.environments[1] ]]"

GitLab Runner 19.0 добавляет инструментирование исполнителя, первый промежуток трассировки для выполнения задания, клиент экспорта OTLP и тайм-аут для этапа подготовки. Также исправлены проблемы с кэшем S3, кодами завершения Windows и исполнителем Kubernetes.

Для команд со многими исполнителями это не декоративное обновление, а способ лучше видеть, где возникает задержка или сбой: в подготовке задания, кэше, исполнителе или внешнем сервисе. Такие детали упрощают поддержку GitLab CI/CD и помогают быстрее восстанавливать выполнение сборок.

Несовместимые изменения для собственных инсталляций GitLab

Для собственных инсталляций GitLab важнейшее требование, PostgreSQL 17. Если используется пакетный PostgreSQL 16, его необходимо обновить перед установкой GitLab 19.0. Поддержка Redis 6 убрана, поэтому внешние экземпляры следует мигрировать на Redis 7.2 или Valkey 7.2.

Пакеты Ubuntu 20.04 больше не предоставляются: GitLab 18.11 был последним релизом с поддержкой этой системы.

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

Kubernetes и Envoy Gateway

Для Kubernetes важно, что GitLab Helm-чарт теперь по умолчанию использует Gateway API из Envoy Gateway. Предыдущую схему входящего трафика Kubernetes на базе NGINX можно временно вернуть, но ее планируют убрать в GitLab 20.0. Кроме того, из Helm-Чарта и GitLab Operator удалены встроенные компоненты Bitnami PostgreSQL, Bitnami Redis и MinIO.

Это изменяет подход к тестовым Kubernetes-развертываниям. Компоненты, которые раньше можно было быстро поднять вместе с чартом, лучше выносить в отдельные управляемые сервисы. Для рабочей среды это логичнее, но при миграции требуется дополнительная проверка файлов values.yaml и сетевых правил.

План обновления GitLab

Перед переходом на GitLab 19.0 желательно пройти короткий чек-лист:

1. Проверьте текущую версию и официальный путь обновления GitLab.

2. Обновите PostgreSQL 17 и проверьте Redis 7.2.

3. Убедитесь, что Ubuntu 20.04 не используется.

4. Протестировать GitLab Runner 19.0 и основной конвейер CI/CD.

5. Проверьте Kubernetes, Helm, Envoy Gateway и внешние сервисы.

6. Отдельно протестировать GitLab Secrets Manager, GitLab Duo и сканирование безопасности.

sudo gitlab-rake gitlab:env:info
sudo gitlab-ctl status
sudo gitlab-ctl pg-upgrade
sudo gitlab-ctl reconfigure

После тестового запуска следует проверить создание запроса на слияние, запуск основных конвейеров, доступ к секретам, отчеты сканирования безопасности и работу исполнителей. Если эти сценарии проходят без ошибок, переход на GitLab 19.0 будет гораздо более прогнозируемым.

Релиз GitLab 19.0 показывает, что GitLab становится более цельной DevOps-платформой для кода, AI, безопасности и инфраструктуры. GitLab Duo переходит в агентные сценарии, GitLab Secrets Manager добавляет встроенное управление секретами, а SBOM-сканирование усиливает контроль зависимостей. Если подготовить обновления GitLab заранее, GitLab 19.0 даст команде больше прозрачности и контроля за полным циклом разработки.

Подписывайтесь на наш Telegram-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов

Напишите в комментариях, как вы пережили апдейт.

Смотрите наш канал YouTube на https://www.youtube.com/freehostua.

Мы в чем-то ошиблись, или что-то пропустили?

Напишите об этом в комментариях, мы с удовольствием ответим и обсуждаем Ваши замечания и предложения.

Дата: 08.06.2026 Автор: Илья Пигович #automation#devops#gitlab#linux

Голосование 1 2 3 4 5