GitLab 19.0 вышел 21 мая 2026 года и сразу закрыл одну из самых неприятных дыр в повседневном DevOps-бытe: хранение секретов прямо внутри платформы, где живут код и пайплайны. Для русскоязычных команд это не просто еще один мажорный релиз, а сигнал: рынок DevSecOps все активнее собирает безопасность, автоматизацию и AI-помощников в одном окне, чтобы не размазывать ответственность по пяти сервисам и десяти интеграциям.
Как пишет The New Stack, в центре релиза оказался GitLab Secrets Manager, который в версии 19.0 перешел в публичную бету для клиентов Premium и Ultimate. Идея простая, но болезненно актуальная: секреты больше не должны жить в переиспользуемых CI/CD variables, конфигурационных файлах или временных .env, которые «сейчас закоммитим на минутку, потом уберем». В новой модели секрет хранится в GitLab, привязывается к конкретным job и выдается только тем пайплайнам, которые явно его запросили. Если credential утек, команда может посмотреть по audit trail, какие job его использовали и из какого pipeline он пришел, а не собирать картину инцидента по внешним логам.
На практике это удар именно по тому сценарию, который разработчики и SRE знают слишком хорошо: секреты формально спрятаны, но по факту имеют слишком широкий радиус поражения. GitLab делает ставку на более жесткое разграничение. Доступ к секретам управляется через те же группы и проекты, что и доступ к коду, без отдельной модели прав. Для компаний это важный аргумент: еще один vault-подобный сервис почти всегда означает отдельную аутентификацию, отдельную политику доступа и отдельный поток аудита. GitLab, напротив, продает идею «меньше переключений, меньше ручной синхронизации, меньше шансов оставить старые доступы бывшему сотруднику или сервису, который давно никому не нужен».
При этом GitLab не пытается делать вид, что внешние хранилища секретов больше не нужны никому и никогда. В релизных материалах компания отдельно подчеркивает совместимость с уже существующими интеграциями: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault и Google Cloud Secret Manager никуда не делись. То есть GitLab 19.0 предлагает не лобовую замену всего стека, а более реалистичный путь: часть команд может перенести секреты внутрь GitLab, а часть оставить в привычной инфраструктуре и двигаться постепенно. Для крупных организаций с гибридным ландшафтом это, пожалуй, единственный рабочий сценарий, потому что «выключаем старое в пятницу вечером» в корпоративном DevSecOps обычно заканчивается плохо.
Второй большой блок релиза касается AI-функций, но не в жанре «ассистент написал пару строк кода и все счастливы». GitLab 19.0 расширяет Developer Flow на весь жизненный цикл merge request: от реакции на замечания ревьюеров до разрешения конфликтов, разбиения слишком больших MR и финального rebase-and-merge в один клик для команд, использующих semi-linear или fast-forward merge. Здесь интереснее всего не сама автоматизация, а то, что GitLab пытается втащить AI в процедурную часть разработки, где обычно теряется больше времени, чем на генерации кода как таковой. Система читает проектные правила из AGENTS.md перед коммитом, чтобы действовать не по усредненному шаблону, а с учетом локальных договоренностей команды.
Это важный сдвиг в логике инструментов для разработки. Еще год назад многие AI-фичи в DevTools сводились к «допиши функцию» или «объясни ошибку». Теперь вендоры заходят на территорию инженерного процесса: кто что мержит, как устраняются конфликты, как соблюдаются внутренние стандарты, как не сломать release train. GitLab здесь явно хочет занять позицию не просто CI/CD-платформы, а центрального диспетчера для кода, политики безопасности и агентных сценариев. Не случайно в пресс-материалах релиз описывается как шаг к сокращению ручных передач работы между написанием кода и выпуском изменений в прод.
Есть и более приземленные, но для платформенных команд не менее полезные новинки. Components Analytics показывает, какие компоненты из CI/CD Catalog реально используются в организации и в каких версиях. Это уже история не про красивую витрину reusable-компонентов, а про наблюдаемость внутри собственной инженерной фабрики: какие шаблоны прижились, где сидят устаревшие версии, что придется обновлять централизованно, если возникает уязвимость или меняется стандарт. Для компаний с несколькими десятками команд это выглядит не как «nice to have», а как минимальный набор здравого смысла.
Отдельный пункт релиза адресован тем, кто по регуляторным или внутренним причинам не может отправлять код во внешние AI-API. В GitLab Duo Agent Platform Self-Hosted добавили поддержку четырех open source моделей: Mistral Devstral 2 123B, GLM-5.1, Kimi-K2.6 и MiniMax-M2.7. Поддерживаются on-premise и private cloud-сценарии, включая запуск через vLLM на GPU-инфраструктуре. Для банков, телекомов, интеграторов и вообще всех, у кого слово «air-gapped» звучит в рабочих созвонах чаще, чем хотелось бы, это полезнее любой маркетинговой риторики про «агентное будущее».
Наконец, GitLab усилил и блок supply chain security. В версии 19.0 dependency scanning с использованием SBOM стал частью истории про более внятный контроль того, что именно попадает в сборку. Для Ultimate-пользователей это означает более аудируемую картину по сторонним компонентам и меньше причин держать отдельный инструмент только ради базовой прозрачности цепочки поставки. В комплекте идут и security configuration profiles, то есть попытка навести порядок не только в находках, но и в самих правилах проверки.
Если смотреть на GitLab 19.0 без презентационных метафор про оркестр, получается довольно прагматичная картина. Платформы разработки все меньше конкурируют отдельными функциями и все больше соревнуются в том, кто убедительнее соберет вокруг кода безопасность, автоматизацию и AI-операции без лишнего зоопарка сервисов. Вопрос уже не в том, нужен ли командам нативный secrets manager или AI-помощник для MR, а в том, готовы ли они доверить одному вендору сразу слишком большую часть инженерного контура. Подробности первоисточника можно посмотреть у The New Stack .
The post GitLab 19.0 добавил Secrets Manager и усилил DevSecOps appeared first on iTech News.