Реліз GitLab 19.0: що змінилося в DevOps-платформі

21 травня 2026 року вийшов реліз GitLab 19.0 — мажорне оновлення платформи, у якому GitLab змістив акцент від окремих інструментів до керованої автоматизації циклу розробки. Якщо версії 18.x поступово додавали AI-функції, профілі безпеки та покращення пайплайнів, то GitLab 19.0 збирає ці напрямки в ціліснішу модель: код, ревʼю, секрети, dependency scanning і деплой працюють ближче один до одного.

Для команд, які розгортають GitLab у власній інфраструктурі, реліз GitLab 19.0 важливий ще й практично. self-managed GitLab отримав нові мінімальні вимоги, зміни в Helm-розгортаннях і оновлення GitLab Runner 19.0. Перед апгрейдом варто перевірити сумісність бази даних, кешу, ОС та Kubernetes-стеку. Якщо потрібне окреме середовище для CI/CD, тестових стендів або GitLab Self-Managed, зручно одразу дивитися в бік VPS для GitLab, де можна ізолювати runner-и й резервні копії.

Головна ідея GitLab 19.0

GitLab давно позиціонує себе як DevOps-платформа, але у версії 19.0 ця ідея стає помітнішою. Раніше багато дій залишалися розірваними: розробник відкривав issue, створював merge request, окремо запускав перевірки, вручну розбирав merge conflicts, а security-команда аналізувала результати security scanning. Тепер частина цієї роботи переноситься в GitLab Duo та Agentic AI, але з обмеженнями, журналюванням і контролем дозволених агентів.

У порівнянні з попередніми релізами, це не набір косметичних правок. Оновлення розраховане на команди, які хочуть скоротити ручні дії в GitLab CI/CD, але не втратити контроль. Саме тому поруч ідуть GitLab AI, GitLab Secrets Manager, нові правила для merge request, покращення SBOM і breaking changes для інфраструктури.

GitLab Duo та GitLab AI: більше агентності в робочому процесі

Один із центральних акцентів версії — GitLab Duo. GitLab Duo Developer отримав кілька способів запуску: його можна призначити на issue, викликати через Generate MR або згадати в обговоренні issue чи merge request. За наявності AGENTS.md і agent-config.yml агент здатен виконувати тести перед комітом, тобто автоматизація розробки вже не обмежується генерацією коду.

GitLab Duo також допомагає з merge conflicts. Це beta-функція, але напрям зрозумілий: GitLab AI аналізує конфлікт, редагує файли, створює коміт у вихідній гілці й додає пояснення для ревʼюерів. Правила захищених гілок залишаються чинними. Для code review зʼявилися групові інструкції: замість дублювання правил у кожному репозиторії команда задає спільні вимоги на рівні групи.

Agentic AI і керування дозволами

GitLab Duo Core переходить на usage-based billing, а Duo Chat для користувачів Core працює поверх GitLab Duo Agent Platform. Це сигнал, що Agentic AI у GitLab розглядається не як чат поруч із кодом, а як шар AI orchestration для задач, що проходять через CI pipelines, ревʼю й виправлення вразливостей. Для self-hosted інсталяцій додано підтримку Gemini та кількох open source models.

Щоб така агентність не перетворилася на хаос, зʼявилися per-session approvals. Користувач може дозволити інструмент на одну сесію, а адміністратор задає політику на рівні інстанса, групи або проєкту. Окремо можна обмежити AI Catalog потрібною ієрархією та налаштувати мережевий доступ. Це корисно для enterprise-команд, де infrastructure teams відповідають і за аудит.

GitLab Secrets Manager: керування секретами всередині платформи

GitLab Secrets Manager перейшов у public beta для Premium та Ultimate на GitLab.com і GitLab Self-Managed. Раніше функція була доступна лише закритій beta-аудиторії, а більшість команд використовувала змінні GitLab CI/CD або зовнішні сховища. Новий підхід дає Owners можливість зберігати секрети в GitLab та видавати їх тільки тим job, які явно їх запитують.

Це важливе покращення для DevSecOps: секрет не потрапляє автоматично в кожен CI/CD pipeline, а доступ описується у конфігурації. GitLab Secrets Manager підтримує проєктні й групові секрети, обмеження за environment, branch, protected-гілками й rotation reminder. Для audit logging модель зрозуміліша: видно, хто керує секретом і які jobs мають право його отримати. Поки функція має beta-статус, для production її варто тестувати обережно.

deploy:
  stage: deploy
  secrets:
    KUBE_CA_PEM:
      gitlab_secrets_manager:
        name: kube-cert
  script:
    - kubectl config set-cluster prod --certificate-authority="$KUBE_CA_PEM"

Для роботи з такими секретами потрібен GitLab Runner 19.0 або новіший. Це ще одна причина не розглядати оновлення GitLab як ізольований апгрейд вебчастини: runner-и, шаблони pipeline і права доступу потрібно перевіряти разом.

Dependency scanning, SBOM і security scanning

У security-блоці найбільш помітна зміна — SBOM-based dependency scanning став generally available для Ultimate. SBOM, тобто software bill of materials, дає повніший опис залежностей проєкту, включно з транзитивними пакетами. Для Maven, Gradle і Python GitLab може автоматично будувати граф, а якщо це неможливо, переходить до manifest scanning.

У попередніх підходах dependency scanning часто бачив лише залежності верхнього рівня. Це залишало сліпу зону: вразливості залежностей могли приходити через пакет, який команда напряму не встановлювала. У GitLab 19.0 SBOM-аналізатор покриває більше випадків, а для Gradle може автоматично створювати gradle.graph.txt. Це зменшує ручні кроки в GitLab CI/CD і робить security scanning ближчим до реального складу збірки.

Автоматичне виправлення і звіти в merge request

Версія додає експериментальне auto remediation для Ruby-залежностей: якщо сканування знаходить вразливий пакет із відомим виправленням, GitLab може відкрити merge request із оновленням версії. Такий MR проходить стандартний review та approvals. У merge request також зʼявилася вкладка Reports із результатами security scans і code quality.

Покращення GitLab CI/CD та GitLab Runner 19.0

GitLab CI/CD у релізі отримав кілька точкових змін. CI/CD inputs краще працюють з масивами: можна звертатися до елементів через індекс, а в UI pipeline вибирати кілька значень зі списку. Для запусків на кількох середовищах це спрощує автоматизація CI/CD без саморобних shell-обхідних шляхів.

Зʼявився перегляд usage details для компонентів із CI/CD Catalog: платформа показує, які проєкти використовують компонент, у якій версії та чи відстають вони від актуальної. Для великих організацій це замінює пошук по сотнях .gitlab-ci.yml.

GitLab Runner 19.0 вийшов одночасно з основним релізом. Серед змін — instrumentation для feature negotiation, OTLP export client, перший job_execution span і configurable prepare stage timeout. Це дає кращу спостережуваність runner-ів і більше контролю над підготовкою job. Runner-и варто тестувати разом із GitLab upgrade.

Інші зміни для розробників

• Rapid Diffs beta. Перегляд змін у великих merge request завантажується швидше.
• Шаблони назв MR. Проєкт може задавати default merge request title template.
• HMAC для webhooks. Підпис webhook-id, timestamp і payload допомагає відсікти replay-атаки.
• Cross-project pushes. CI_JOB_TOKEN може пушити в інший проєкт за opt-in та ролі Developer.
• Mermaid 11. Діаграми в Markdown отримали новішу версію рендерера.

Зміни для self-managed GitLab

Найбільша зона ризику — інфраструктура. Для self-managed GitLab мінімальною підтримуваною версією бази став PostgreSQL 17. Якщо використовується packaged PostgreSQL 16, його потрібно оновити до встановлення GitLab 19.0. Підтримку Redis 6 прибрали: зовнішні інсталяції мають перейти на Redis 7.2 або Valkey 7.2. Linux packages більше не постачаються для Ubuntu 20.04; останньою версією з пакетами для цієї ОС була GitLab 18.11.

Окрема група змін стосується Kubernetes. GitLab Helm chart за замовчуванням переходить із NGINX Ingress на Gateway API з Envoy Gateway. Якщо міграція поки неможлива, bundled NGINX можна явно повернути до GitLab 20.0. Для Kubernetes ingress це помітний архітектурний зсув. Також із Helm chart та GitLab Operator прибрали bundled Bitnami PostgreSQL, Redis і MinIO: тепер потрібні зовнішні сервіси.

Як підготувати GitLab upgrade

Реліз GitLab 19.0 не варто ставити за принципом “оновимо пакет і подивимося”. Це мажорна версія із залежностями від інфраструктури. Перед GitLab upgrade доцільно пройти короткий чекліст:

1. Перевірити поточну версію GitLab, GitLab Runner, PostgreSQL, Redis або Valkey.
2. Переконатися, що ОС підтримується, а резервні копії створюються та відновлюються.
3. Протестувати GitLab Secrets Manager, якщо планується перенесення секретів із CI/CD Variables.
4. Запустити тестовий CI/CD pipeline із dependency scanning і SBOM, щоб оцінити час сканування.
5. Перевірити Kubernetes-розгортання: GitLab Helm chart, Gateway API, Envoy Gateway і зовнішні сервіси.
6. Підготувати команду до змін GitLab Duo: credits, approvals, AI Catalog і мережеві політики.

# Приклад базової перевірки перед апгрейдом
gitlab-rake gitlab:env:info
gitlab-psql --version
redis-cli INFO server
gitlab-runner --version

Чи варто оновлюватися одразу

GitLab 19.0 виглядає сильним релізом для команд, які вже активно використовують GitLab CI/CD, security scanning і GitLab Duo. Найбільшу користь отримають організації з багатьма репозиторіями: групові AI-інструкції, component usage details, SBOM, Reports tab і GitLab Secrets Manager зменшують ручну роботу.

Водночас для self-managed інсталяцій це не “тихе” оновлення GitLab. PostgreSQL 17, Redis 7.2, відмова від Ubuntu 20.04, зміни в Kubernetes і GitLab Runner 19.0 вимагають плану, тестового середовища й вікна обслуговування. Якщо інфраструктура готова, реліз GitLab 19.0 можна розглядати як крок до керованішої DevOps-платформи, де AI допомагає не лише писати код, а й доводити зміни до безпечного постачання.

Залишити коментар

Опубліковано Максим на 02 06 2026. Поданий під Технології. Ви можете слідкувати за будь-якими відповідями через RSS 2.0. Ви можете подивитись до кінця і залишити відповідь.