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

Зміст:

• Що головне в 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