Мы с радостью объявляем о релизе GitLab 16.8 с поддержкой менеджера секретных ключей GCP, возможностью ускорения сборок с прокси зависимостей Maven, общим доступом к рабочим пространствам, новым представлением DevOps c бенчмарками на основе DORA и многими другими фичами!
Это лишь несколько из более 25 улучшений, добавленных в этом релизе. Читайте дальше, чтобы узнать обо всех основных изменениях.
Мы благодарны участникам сообщества GitLab за 207 изменений, которые вы внесли в релиз 16.8. В GitLab каждый может сделать свой вклад, и ваш вклад в этот релиз неоценим!
Чтобы заранее узнать, что запланировано на следующий месяц, посмотрите страницу наших будущих релизов — на ней есть видео, посвящённое релизу 16.9.
Ted оставил существенный вклад, поскольку несколько раз удалял старый и неиспользуемый код из наших вспомогательных файлов и выполнил много других задач по сопровождению GitLab. Он был номинирован Kerri Miller, штатным инженером GitLab, которая говорит: «Это не самая престижная работа, но она безусловно очень важна».
Ted — разработчик, работающий на фрилансе, любитель скалолазания и кошек из Оринджа, Калифорния.
Martin был номинирован Viktor Nagy, продакт-менеджером GitLab: «Он добавил много недостающих тестов в шаблон заданий Auto Deploy и улучшил документацию по Helm-чартам агента GitLab для Kubernetes».
Lee Tickett, инженер GitLab, добавляет, что Martin «участвовал в рабочих сессиях GitLab в Discord и тесно сотрудничал с членами команды, чтобы внести свой вклад в крайне востребованную фичу — улучшение поиска для мерж-реквестов».
Martin — IT-архитектор в компании Deutsche Telekom MMS GmbH в Дрездене, Германия.
Helio был номинирован Hannah Sutor](https://gitlab.com/hsutor), главным менеджером по продукту GitLab. Hannah говорит, что он «подтолкнул всю нашу команду вперёд, предложив возможность входа в систему с использованием ключей доступа. Мерж-реквест (в русской локализации GitLab «запрос на слияние») Helio был закрыт, однако его вклад был глубоким и наводящим на размышления, а его вопросы и обсуждения сделают нашу реализацию Passwordless значительно лучше».
Helio — инженер-программист, любящий Ruby и OSS.
Спасибо, Ted, Martin и Helio за этот вклад! ????
(Доступно в планах SaaS: PREMIUM, ULTIMATE; Self-Managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Секретные ключи, которые хранятся в GCP Secret Manager, теперь можно будет легко извлекать и использовать в заданиях CI/CD. Наша новая интеграция упрощает взаимодействие с GCP Secret Manager через GitLab CI/CD, помогая вам оптимизировать процессы сборки и развёртывания. Это — всего лишь одна из множества причин, по которым GitLab и Google Cloud выгодно использовать вместе.
Документация по интеграции GCP Secret Manager и оригинальный эпик.
(Доступно в планах SaaS: PREMIUM, ULTIMATE; Self-Managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Мы рады сообщить, что рабочие пространства теперь доступны для пользователей с любыми планами подписки. Приготовьтесь повысить эффективность ваших процессов разработки!
Создавая загружаемые по требованию безопасные окружения разработки, вы можете сократить время, которое требуется на управление зависимостями и онбординг новых участников команды, и сосредоточить усилия на более быстрой поставке чего-то полезного. Рабочие пространства не зависят от платформы, что позволяет вам использовать существующую облачную инфраструктуру для самостоятельного хостинга своих рабочих пространств и обеспечения конфиденциальности и безопасности ваших данных.
С момента добавления рабочих пространств в релизе GitLab 16.0 в них было добавлено множество улучшений для обработки и исправления ошибок. Также были добавлены поддержка приватных проектов и SSH-соединений, дополнительные параметры настройки и новый интерфейс администратора. Эти улучшения сделали рабочие пространства более гибкими, надёжными и удобными для управления при больших объёмах.
Документация по рабочим пространствам и оригинальный эпик.
(Доступно в планах Self-Managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Govern
В этом релизе мы добавили настройку, позволяющую требовать обязательного использования двухфакторной аутентификации (2FA) администраторами GitLab в инстансах с самостоятельным управлением. Использование 2FA — хорошая практика для любых учётных записей, но оно особенно важно для учётных записей с высоким уровнем привилегий, таких как администраторы. Если эта настройка активирована, и 2FA ещё не используется, администратору будет необходимо её настроить при следующем входе в систему.
Документация по принудительному использованию 2FA для администраторов GitLab и оригинальный тикет.
(Доступно в планах SaaS: PREMIUM, ULTIMATE; Self-Managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Типичный проект по разработке ПО опирается на множество зависимостей, которые мы называем пакетами. Пакеты могут создаваться и поддерживаться внутри компании, или их можно получать из общедоступных репозиториев. Согласно статистике, собранной на основе пользователей GitLab, в большинстве проектов GitLab используется соотношение 50/50 общедоступных и собственных пакетов. При этом очень важно соблюдать порядок установки пакетов, поскольку использование неправильной версии может привести к серьёзным проблемам и уязвимостям в ваших конвейерах (в русской локализации GitLab «сборочная линия»).
Теперь вы можете добавить в свой проект GitLab один внешний репозиторий Java. После его добавления при установке пакета с помощью прокси-сервера зависимостей, GitLab сначала будет проверять наличие этого пакета в проекте. Если он не будет найден, GitLab попытается получить пакет из внешнего репозитория.
Когда вы загружаете пакет из внешнего репозитория, он импортируется в проект GitLab. В следующий раз, когда этот конкретный пакет будет использоваться, он будет загружен не из внешнего репозитория, а из GitLab. Таким образом, даже если у внешнего репозитория возникают проблемы с подключением и пакет присутствует в прокси-сервере зависимостей, извлечение пакета всё равно работает, что делает ваши конвейеры быстрее и надёжнее.
Если пакет изменяется во внешнем репозитории (например, пользователь удаляет версию и публикует новую с другими файлами), прокси-сервер зависимостей это заметит. Загруженный пакет становится недействительным, поэтому GitLab извлекает более новую версию. Это гарантирует постоянное наличие рабочих версий пакетов и помогает снизить количество уязвимостей.
Документация по прокси зависимостей и оригинальный эпик.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Plan
Отчёт Аналитика тикетов теперь содержит информацию о числе закрытых тикетов (в русской локализации GitLab «обсуждение») в месяц, что позволяет производить более детальный анализ скорости процессов разработки. С этим дополнением пользователи GitLab смогут оценивать тренды, связанные с их проектами, и снизить время разработки и повысить ценность, поставляемую клиентам. Визуализация данных отчёта Аналитика тикетов содержит гистограмму с числом тикетов за каждый месяц. По умолчанию отображается 13 месяцев. Вы можете посмотреть этот график в детальном представлении на панели аналитики цикла разработки.
Документация по аналитике тикетов и оригинальный тикет.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Plan
Мы добавили новую панель DORA Performers score на панель аналитики цикла разработки, чтобы отображать статус работы DevOps в нескольких проектах одновременно. Эта панель содержит наглядную информацию об оценках метрик DORA, что поможет менеджерам проектов получать полное представление о состоянии DevOps-процессов в организации.
Четыре метрики DORA доступны в базовой версии GitLab, а теперь, с визуализацией оценок DORA, организации смогут сравнивать производительность своих DevOps-процессов со средними показателями по отрасли или с конкурентами. Это поможет руководителям определить слабые и сильные места своей организации по сравнению с другими.
Если вы хотите помочь нам улучшить панель аналитики цикла разработки, пройдите опрос, чтобы рассказать о своём опыте.
Документация по панели измерения производительности и оригинальный тикет.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Plan
Мы представляем новую страницу описания для панели аналитики группы, которая обеспечит более последовательную и удобную навигацию. На первом этапе эта страница включает в себя аналитику цикла разработки, но она также закладывает основу для будущих улучшений, которые позволят вам персонализировать информационные панели. Эти улучшения направлены на оптимизацию пользовательского опыта и обеспечение большей гибкости в управлении вашими данными и их анализе.
Документация по аналитике цикла разработки и оригинальный тикет.
(Доступно в планах SaaS: PREMIUM, ULTIMATE; Self-Managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Улучшенный опыт разработки, удобный онбординг и безопасность способствуют активному развитию облачных IDE и сред разработки с загрузкой по требованию. Однако эти окружения могут требовать больших затрат на инфраструктуру. У вас уже есть возможность настраивать использование ресурсов ЦП и памяти в рамках проекта в вашем devfile.
Теперь вы также можете настроить использование ЦП и памяти для каждого рабочего пространства. Настраивая запросы и ограничения на уровне агента GitLab, вы можете запретить отдельным разработчикам использовать слишком много облачных ресурсов.
Документация по настройкам удалённой разработки агента GitLab и оригинальный эпик.
(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; Self-Managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
В предыдущих версиях GitLab, чтобы просмотреть результат git blame для файла, требовалось перейти на другую страницу. Теперь эта информация доступна прямо на странице файла.
Документация по просмотру git blame для файла и оригинальный эпик.
(Доступно в планах Self-Managed: ULTIMATE) Стадия цикла DevOps: Verify
По разным причинам вам может потребоваться отчёт о вычислительных минутах CI/CD, использованных проектами в инстансах GitLab. Однако ранее в GitLab не было простого в использовании механизма для создания такого отчёта. С помощью нашей новой фичи можно экспортировать в CSV-файл отчёт о минутах вычислений CI/CD, использованных каждым проектом на общих обработчиках заданий.
Документация по экспорту отчёта по вычислительным минутам и оригинальный тикет.
(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; Self-Managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Deploy
В этом релизе добавлена полная поддержка Kubernetes версии 1.28, выпущенной в августе 2023 года. Если вы развёртываете свои приложения на Kubernetes, теперь можно обновить свои подключённые кластеры до последней версии и пользоваться всеми её фичами.
В документации вы можете узнать больше о наших правилах поддержки Kubernetes и других поддерживаемых версиях Kubernetes.
Документация о поддерживаемых версиях Kubernetes(https://docs.gitlab.com/ee/user/clusters/agent/#supported-cluster-versions) и оригинальный тикет.
(Доступно в планах SaaS: PREMIUM, ULTIMATE; Self-Managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Govern
Наш центр соответствия требованиям постепенно становится центральным пунктом, из которого можно оценивать ситуацию с соответствием и управлять платформами, обеспечивающими это соответствие. В этом релизе мы переносим управление платформами на новую вкладку в центре соответствия, а также добавляем новые интересные возможности:
Просмотр платформ в виде списка на вкладке Платформы (Frameworks).
Поиск и фильтрация для нахождения конкретных платформ.
Новая боковая панель платформ, позволяющая получить более подробную информацию о каждой платформе.
Редактирование платформы для просмотра всех настроек, включая управление именем, описанием, связанными проектами и т. д.
Создание быстрого отчёта с экспортом в CSV о ваших платформах.
Документация по платформам соответствия и оригинальный эпик.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Govern
Мы расширили трансляцию событий аудита, чтобы можно было фильтровать события по подгруппе или проекту на уровне группы, в дополнение к существующей поддержке фильтрации по типу события.
Этот дополнительный фильтр позволит разделить события в потоке для отправки в разные пункты назначения или исключить неактуальные подгруппы/проекты, обеспечивая мониторинг наиболее важных событий для вашей команды.
Документация по трансляции событий аудита и оригинальный эпик.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Govern
В этом релизе появилось пять новых возможностей, которые можно использовать для создания пользовательских ролей:
Добавьте эти возможности, а также другие уже существующие пользовательские возможности к любой базовой роли, чтобы создать пользовательскую роль. Пользовательские роли позволяют определять роли с детализированными разрешениями, которые предоставляют пользователю только те возможности, которые необходимы для выполнения его работы, и уменьшают ненужную эскалацию привилегий.
Документация по использованию пользовательских ролей(https://docs.gitlab.com/ee/user/custom_roles.html) и оригинальный тикет.
(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; Self-Managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan
В этом релизе можно просмотреть всю иерархию рабочего элемента (например, задачи, цели или ключевого результата), а не только его непосредственного родителя.
Документация по целям и ключевым результатам и оригинальный эпик.
patch-id
(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; Self-Managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Чтобы гарантировать, что все изменения проверены и одобрены, при добавлении новых коммитов в мерж-реквест все подтверждения обычно удаляются. Однако перебазирование (git rebase) также отменяло существующие подтверждения, даже если при этом не вносилось новых изменений. В результате требовалось повторное подтверждение.
Теперь одобрения мерж-реквестов зависят от git-patch-id
. Этот идентификатор достаточно стабилен и уникален, что позволяет принимать более обоснованные решения о сбросе одобрений. Сравнивая patch-id
до и после перебазирования, можно определить, были ли внесены новые изменения, из-за которых надо отменить подтверждение и провести ревью снова.
Если у вас есть мнение об удобстве использования нового варианта отмены подтверждений, сообщите нам об этом в тикете #435870.
Документация по отмене подтверждений при добавлении коммитов и оригинальный эпик.
(Доступно в планах SaaS: PREMIUM, ULTIMATE; Self-Managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
По мере того как растёт количество элементов в каталоге CI/CD, становится всё сложнее находить компоненты CI/CD, выпущенные вашими группами и доступные вам. В этом релизе мы представляем специальную вкладку Ваши группы (Your groups), позволяющую легко фильтровать и находить компоненты, связанные с вашей организацией. Этот упрощённый процесс поиска повышает эффективность, поскольку можно быстрее находить и использовать выпущенные ранее компоненты CI/CD.
Документация по каталогу CI/CD(https://docs.gitlab.com/ee/ci/components/#cicd-catalog) и оригинальный тикет.
(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; Self-Managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Если вы используете автоматизацию для работы с мерж-реквестами в конвейерах CI/CD, возможно, вам нужен более простой способ получения описания мерж-реквеста без использования API. В GitLab 16.7 мы представили предопределённую переменную CI_MERGE_REQUEST_DESCRIPTION
, что сделало описание легко доступным во всех заданиях. В GitLab 16.8 мы изменили поведение, сокращая содержимое CI_MERGE_REQUEST_DESCRIPTION
до 2700 символов, поскольку очень большие описания могут вызвать ошибки в обработчике заданий. Теперь можно проверить, было ли описание сокращено, с помощью недавно введённой предопределённой переменной CI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATED
, которая получает значение true
, если сокращение произошло.
Документация по предопределённым переменным для конвейеров и оригинальный тикет.
(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Команды теперь могут создавать, тестировать и развёртывать приложения на Windows Server 2022.
Обработчики заданий SaaS на Windows позволяют увеличить скорость работы команд разработчиков при создании и развёртывании приложений, требующих Windows, в безопасном окружении сборки GitLab Runner, доступном по требованию и интегрированным с GitLab CI/CD.
Попробуйте эту фичу уже сегодня, используя тег saas-windows-medium-amd64
в вашем файле .gitlab-ci.yml.
Документация по обработчиков заданий SaaS для Windows и оригинальный тикет.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Govern
Пользователям можно назначить кастомную роль в качестве роли по умолчанию, с которой они создаются при предоставлении доступа с помощью SAML SSO. Ранее в качестве роли по умолчанию можно было выбрать только статические роли. Теперь можно автоматически создаваемым пользователям назначать роль, которая лучше всего соответствует принципу наименьших привилегий.
Документация по настройке SAML SSO и оригинальный тикет.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Govern
Как одна из нескольких новых настроек, добавленных в правила результатов сканирования, чтобы помочь в обеспечении соблюдения правил безопасности, элементы управления модификацией веток будут ограничивать возможность обходить правила, изменяя настройки на уровне проекта.
Для каждого существующего или нового правила результатов сканирования можно включить Препятствовать изменению веток
(Prevent branch modification
). Эта функция будет работать для веток, определённых в рамках этого правила, и пользователи не смогут удалять такие ветки или снимать с них защиту.
Документация по настройке правил безопасности(https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) и оригинальный эпик.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Govern
Раньше для AWS S3 можно было настроить трансляцию событий аудита только для групп верхнего уровня.
С GitLab 16.8 мы расширили поддержку AWS S3 до адресатов потоковой передачи на уровне инстанса.
Документация по трансляции событий аудита для AWS S3 и оригинальный эпик.
(Доступно в планах SaaS: ULTIMATE; Self-Managed: ULTIMATE) Стадия цикла DevOps: Govern
Теперь можно использовать SAML Group Sync для сопоставления кастомных ролей с группами пользователей. Ранее вы могли сопоставлять группы SAML только со статическими ролями GitLab. Это улучшение даёт больше гибкости клиентам, которые используют SAML Group Links для управления членством в группах и ролями участников.
Документация по настройке SAML Group Sync и оригинальный тикет.
(Доступно в планах SaaS: PREMIUM, ULTIMATE; Self-Managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Govern
Те, кто использует единый вход через SAML и SCIM для управления учётными записями пользователей в GitLab, теперь могут использовать его для удовлетворения требований аутентификации мерж-реквеста вместо аутентификации на основе пароля для утверждения мерж-реквестов.
Этот метод гарантирует, что только аутентифицированные пользователи могут подтверждать мерж-реквест в целях безопасности и соответствия нормативным требованиям, без необходимости использовать отдельное решение на основе паролей.
Документация по настройке аутентификации для подтверждения мерж-реквестов и оригинальный эпик. Полный текст релиза и инструкции по обновлению и установке вы можете найти в оригинальном англоязычном посте GitLab 16.8 released with Google Cloud Secret Manager support and the ability to speed up your builds with the Maven dependency proxy. Над переводом с английского работали @maryartkey, @ainoneko и @rishavant.