Вышел релиз GitLab 14.1 с реестром Helm Chart и правилами эскалации
Мы рады представить вам релиз GitLab 14.1 с возможностью собирать, публиковать и распространять Helm-чарты, создавать правила эскалации для ответственных за страницу, подключать обработчики заданий GitLab к вашим кластерам Kubernetes, обеспечивать соблюдение решений по покрытию кода и многим другим!
Это — лишь несколько основных из более чем 50 улучшений в этом релизе. Читайте далее, и вы узнаете всё об этих новых фичах. Чтобы узнать, что будет в следующем месяце, зайдите на страницу предстоящих релизов, там вы найдёте видео по будущему релизу 14.2.
А также…
Приглашаем на наши встречи
Если же вам интересно узнать на практике, как работают решения ИБ в контекста GitLab, как мы на практике реализуем работу с уязвимостями и автоматизируем процессы их обнаружения, а также обсудить нашу дорожную карту, приглашаем посеть GitLab Security Virtual Workshop (на английском языке) 27 октября. Регистрация уже открыта!
Learn@GitLab (Центр онлайн-обучения)
MVP этого месяца — Andrew Smith
Andrew принимал активное участие во многих мерж-реквестах в релизе 14.1, помогая улучшить планирование в GitLab. Он внёс значительные улучшения в наши доски задач (в русской локализации GitLab «доски обсуждений») и эпиков (в русской локализации GitLab «цели»). Благодаря его работе пользователи GitLab теперь могут сортировать эпики в списке по названию, просматривать количество открытых тикетов и их суммарный вес и отслеживать прогресс выполнения на досках эпиков, а также просматривать веса в списках майлстоунов (в русской локализации GitLab «этапы»).
Помимо значительного вклада в разработку продукта, Andrew также тесно сотрудничал с нашей командой, помогая выявлять и устранять ошибки и препятствия, которые встречались на его пути.
Спасибо Andrew за то, что он помогает сделать GitLab лучше!
Основные фичи релиза GitLab 14.1
Собирайте, публикуйте и распространяйте Helm-чарты в GitLab
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Helm определяет chart (далее — чарт) как пакет Helm, содержащий все определения ресурсов, необходимых для запуска приложения, инструмента или сервиса в кластере Kubernetes. Для организаций, которые создают собственные Helm-чарты и управляют ими, нужен централизованный репозиторий для их хранения и распространения.
GitLab уже поддерживает множество форматов пакетных менеджеров, почему бы не поддерживать и Helm? Этот вопрос несколько месяцев назад задал участник нашего сообщества и MVP релиза 14.0 Mathieu Parent, перед тем как приступить к работе над новым реестром GitLab Helm chart. Сотрудничество между сообществом и GitLab является частью нашей стратегии двойного маховика и одной из причин, по которым работа в GitLab приносит нам удовольствие. Браво, Mathieu!
Теперь вы можете использовать свой проект GitLab для публикации и распространения упакованных чартов Helm. Просто добавьте свой проект в качестве удалённого ресурса, авторизовавшись с помощью персонального токена доступа, развёртывания или задания CI/CD. После этого вы можете использовать клиент Helm или GitLab CI/CD для управления Helm-чартами. Вы также можете загрузить их с помощью API или через пользовательский интерфейс.
Что будет дальше? Сначала мы хотели бы предоставить дополнительные метаданные для чартов. Затем мы начнём сами использовать эту фичу в GitLab, заменив ею текущий https://charts.gitlab.io/.
Так что попробуйте эту фичу и дайте нам знать, что вы думаете, оставив комментарий в эпике GitLab-6366.
Документация по репозиторию Helm-чартов в GitLab и оригинальный тикет.
Правила эскалации
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor
Быть дежурным сотрудником — это круглосуточная напряжённая работа. Несмотря на все ваши усилия и старания, есть вероятность упустить какое-либо уведомление. Однако команды, обслуживающие критически важные системы, не могут допустить пропуска оповещений об отключениях или перебоях в обслуживании. Правила эскалации являются страховочным механизмом для подобных ситуаций. Они включают в себя шаги с определёнными временными рамками, благодаря которым событие автоматически перенаправляется на ответственного сотрудника из следующего шага, если тот, кто был на предыдущем шаге, не обработал событие. Чтобы защитить свою компанию от пропущенных критических оповещений, создайте правила эскалации в проекте GitLab с расписанием дежурных сотрудников.
В релизе GitLab 14.1 пользователи могут создавать, просматривать и удалять правила эскалации.
Документация по правилам эскалации и оригинальный эпик.
CI/CD-тоннель для кластеров Kubernetes
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure
До сих пор подключение кластеров Kubernetes к GitLab CI/CD требовало от пользователей открывать свои кластеры для GitLab. Некоторые организации не поощряют открытие своего фаервола для внешнего доступа по соображениям безопасности.
GitLab теперь включает в себя CI/CD-тоннель, который соединяет обработчики заданий GitLab с вашим кластером Kubernetes с помощью агента для Kubernetes от GitLab. Это позволяет создавать универсальные рабочие процессы GitOps, в которых логика развёртывания может быть заложена в конвейере (в русской локализации GitLab «сборочная линия»).
Вы и ваша команда можете спокойно работать с вашим любимым инструментом для запуска самого развёртывания, используя kubectl, helm, kpt, tanka или что-то другое без угрозы безопасности.
Чтобы использовать тоннель, определите kubecontext в вашем конвейере CI/CD для соединения с агентом. Чтобы упростить этот процесс, мы планируем автоматически добавлять kubecontext в CI/CD-окружение в будущих итерациях.
В настоящее время тоннель CI/CD поддерживается только из проекта, в котором был настроен агент, но мы работаем над добавлением поддержки на уровне группы. Вы можете смело начинать использовать тоннель на GitLab SaaS и в инстансах с самостоятельным управлением.
Документация по CI/CD-тоннелю и оригинальный эпик.
Новое правило подтверждения мерж-реквестов для покрытия кода
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Чтобы сохранить высокое покрытие кода тестами, необходимо убедиться, что мерж-реквесты (в русской локализации GitLab «запросы на слияние») в вашем проекте никогда не уменьшают покрытие тестами. Ранее единственным способом обеспечить это было требование подтверждения от пользователей, которые вручную проверяли изменение покрытия в рамках ревью.
Теперь вы можете обеспечить соблюдение ваших правил по покрытию с помощью нового правила подтверждения — проверки покрытия. Это простой способ убедиться, что мерж-реквесты, которые уменьшают покрытие тестами, не будут приняты.
Документация по правилу подтверждения Coverage-Check и оригинальный тикет.
Интеграция с Datadog CI Visibility
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Интеграция GitLab с Datadog Continuous Integration Visibility обеспечивает подробную аналитику ваших конвейеров, юнит-тестов и интеграционных тестов. Просматривайте изменения высокоуровневых метрик с течением времени: статусы выполнения, продолжительность, процентили (50-й и 95-й), количество сбоев, время ожидания в очереди и многое другое. Панели Datadog помогут вам разобраться в данных GitLab CI/CD и выявить проблемные задания, которые чаще всего приводят к сбоям конвейеров.
Документация по интеграции с Datadog CI Visibility и оригинальный тикет.
Создавайте таблицы и загружайте изображения через редактор вики-контента
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Мы начали улучшать возможности редактирования вики в релизе GitLab 14.0, когда представили MVC нового WYSIWYG-редактора Markdown. Он поддерживал наиболее распространённые возможности форматирования Markdown-контента, но с некоторыми существенными пробелами. GitLab 14.1 продолжает совершенствовать возможности редактирования, добавляя к ним изображения и таблицы. Теперь вы можете загружать изображения непосредственно в редактор, а также вставлять и редактировать таблицы, в том числе копировать и вставлять содержимое из популярных приложений для работы с электронными таблицами для переноса таблиц из других источников в вашу вики.
Документация по редактору контента для вики и оригинальный тикет.
Выбирайте роль для токена доступа к проекту
(SaaS: PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Теперь при создании токена доступа к проекту пользователи могут указать уровень доступа на уровне проекта, который у него должен быть, а также просматривать существующие роли токенов доступа к проекту.
До этого релиза все токены доступа к проекту были с ролью мейнтейнер (в русской локализации GitLab «сопровождающий»). Для некоторых пользователей эта роль включала расширенные права доступа, которые не были необходимы.
Чтобы исключить злоупотребления полномочиями, мы сделали выбор ролей для токенов проекта доступным для всех пользователей, за исключением бесплатных аккаунтов GitLab SaaS. Все пользователи инстансов с самостоятельным управлением, а также клиенты Premium и Gold SaaS теперь могут легко выбрать или узнать текущую роль для своих токенов доступа к проекту.
Документация по токенам доступа к проекту и оригинальный тикет.
Внешние проверки статуса для мерж-реквестов
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Теперь вы можете обратиться к внешнему API для проверки статуса в мерж-реквесте. Это отличный способ интегрировать GitLab со сторонними системами, которые:
Работают во внешней системе и не имеют специальных заданий на конвейере.
Требуют ручного подтверждения в другой системе.
В проекте можно настроить API для проверки статуса (с помощью пользовательского интерфейса GitLab или API GitLab), а затем, когда в мерж-реквест вносятся изменения, этот API вызывается с различными подробностями о мерж-реквесте. Внешний API может вернуть код ответа, показывающий, прошла ли проверка. Этот результат будет показан в мерж-реквесте.
Это позволяет командам легче взаимодействовать друг с другом и убедиться, что мерж-реквесты соответствуют внешним требованиям, до их мержа, предоставляя ещё один метод обеспечения соответствия требованиям.
Документация по проверкам статуса для мерж-реквестов и оригинальный эпик.
Быстрый доступ к записям отчётов о соответствии
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Мы добавили на панель соответствия требованиям (Compliance Dashboard) новую информацию, быстрый доступ к подробностям мерж-реквеста для просмотра их состояния. Нажмите на мерж-реквест в списке, и вы увидите справа панель с информацией. Теперь вы сможете быстро узнать статус и просмотреть детали мерж-реквеста прямо на панели соответствия.
Это поможет сэкономить время, поскольку добавляет к панели соответствия информацию о каждом мерж-реквесте, такую как автор, название, подтверждающие, комментаторы и т.д. Вам больше не придётся открывать каждый мерж-реквест по отдельности, чтобы получить эту информацию. Команды, отвечающие за соблюдение требований, смогут оперативно ознакомиться с полным списком мерж-реквестов и найти те, которые требуют внимания, вместо того чтобы тратить время на проверку тех, которые в этом не нуждаются.
Документация по панели соответствия требованиям и оригинальный тикет.
Требование наличия связанного с мерж-реквестом тикета Jira
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Теперь вы можете настроить в проекте обязательное связывание с тикетом из Jira для всех мерж-реквестов. Это отличный способ гарантировать, что изменения кода в GitLab будут отражены в тикетах Jira, и команды смогут лучше взаимодействовать друг с другом.
Документация по настройке требования связанного с мерж-реквестом тикета Jira и оригинальный эпик.
Лёгкая настройка DAST через интерфейс
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Динамическое тестирование безопасности приложений (DAST) в GitLab теперь предлагает новую упрощённую схему настройки. Мы считаем, что безопасность — это командная работа, и такая схема настройки облегчает работу с GitLab DAST пользователям, не являющимся экспертами в CI. Этот инструмент помогает пользователю создать мерж-реквест для запуска DAST-сканирования, задействуя при этом лучшие методы конфигурации, такие как использование управляемого GitLab шаблона DAST.gitlab-ci.yml и корректное переопределение настроек по умолчанию.
При использовании DAST в GitLab пользователи часто создают несколько конфигураций, чтобы охватить различные области своего приложения. Новый интерфейс конфигурации DAST позволяет пользователям создавать профили сайта и сканера DAST. Далее на эти профили можно ссылаться в заданиях конвейера CI/CD. Конфигурация хранится в базе данных и используется во время выполнения сканирования для загрузки переменных конфигурации в задание. Единственное, что пользователю надо будет настроить в конфигурации YAML — это указать названия профилей сайта и сканера, которые будут использоваться при сканировании. Благодаря этому становится максимально просто переключать конфигурации, когда этого требует ваше приложение. Создавать конфигурационные файлы YAML для ваших заданий DAST с нуля больше не требуется. Мы можем создать их за вас.
Документация по настройке DAST-сканирований и оригинальный эпик.
Встроенные уведомления о качестве кода в диффах мерж-реквестов
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Verify
Если вы разработчик, создающий или проверяющий мерж-реквест, вы хотите знать, как каждое изменение влияет на качество проекта. Чтобы достичь этого в GitLab, раньше требовалось открыть два окна:
Дифф кода мерж-реквеста
Главную страницу мерж-реквеста с изменениями качества кода.
Такое постоянное переключение неэффективно, и из-за него можно легко упустить проблемы с качеством кода.
Вкладка Изменения (Changes) в мерж-реквесте теперь показывает, в какой строке нарушилось качества кода, и степень его серьёзности, что позволит вам быстро определить наиболее важные проблемы, требующие решения. Наведя курсор на значок, вы получите подробную информацию о нарушении.
Документация по проверке качества кода в мерж-реквестах и оригинальный тикет.
