Вышел долгожданный релиз GitLab 14.0

Когда мы думаем обо всём, что было выпущено за год с момента выхода GitLab 13.0, мы не можем не гордиться нашим сообществом и нашей командой. В этом месяце мы празднуем выход GitLab 14.0, и в связи с этим устроим небольшую ретроспективу. Вместе мы добились такого прогресса за последний год, что нам хочется рассказать обо всём, что потребовалось, чтобы пройти путь до GitLab 14.

Мы используем семантическое версионирование, поэтому релизы вида 14.0 отражают всё новое, что появилось в этом месяце. GitLab 14 же — это кульминация всего прошедшего года. Более того, GitLab 14 отражает будущее GitLab и будущее DevOps в целом.

С выходом GitLab 14 команды любого масштаба смогут перейти от поддержания DIY-инструментов для DevOps к внедрению современного DevOps. GitLab 14 — это полноценная DevOps-платформа со встроенной в её ДНК безопасностью, прозрачностью и аналитикой (которую обеспечивает единое место для хранения данных), а также с цельным рабочим процессом и масштабируемой системой, благодаря чему и конечные пользователи, и организации получают все преимущества скорости и эффективности.

Мы написали пост, в котором вы можете больше узнать о GitLab 14 и нашем видении современного DevOps, и о том, как DevOps позволяет любой команде создавать и поставлять программное обеспечение быстро, прозрачно и надёжно.

Как и всегда, мы рады рассказать обо всех новинках этого месяца в релизе 14.0. Читайте далее нашу постоянную обзорную подборку ключевых новых фич и улучшений релиза. Кроме того, в 14.0 есть несколько кардинальных изменений. Чтобы узнать, что будет в следующем месяце, зайдите на страницу предстоящих релизов, там вы найдёте видео по будущему релизу 14.1

Присоединяйтесь к нам на GitLab Commit Virtual, чтобы узнать, как команды, использующие DevOps, повышают эффективность совместной работы.

MVP этого месяца — Mathieu Parent

Mathieu внёс значительный вклад в нашу стадию Package благодаря своей работе над реестрами пакетов Debian и Helm. Фичи этого направления пока что целиком и полностью принадлежат его авторству.

Работа по внедрению пакетов Debian продолжается с сентября 2020 года. На данный момент было принято уже около 38 мерж-реквестов, и сейчас мы приближаемся к концу итеративного плана, который составил и поддерживал Mathieu. В результате его усилий мы находимся всего в нескольких мерж-реквестах от завершения работы над этой фичей и её выхода.

Mathieu также спланировал разработку менеджера пакетов Helm Charts и работал над ним в течение последних трёх месяцев. В ходе этой работы Mathieu придерживался ценностей GitLab — итеративности и сотрудничества — работая в тесном контакте со всей командой Package (и не только) над этими и многими другими фичами.

Спасибо за всю эту потрясающую работу, Mathieu!

Основные фичи релиза GitLab 14.0

Доски эпиков

(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan

Доски эпиков (в русской локализации GitLab «цели») помогут наладить работу команд и организаций за счёт непрерывного информирования о состоянии эпиков. В предыдущих версиях GitLab для отслеживания общего состояния эпиков требовалось просматривать и сортировать их в списке. Для поддержания эпиков в актуальном состоянии большинство изменений приходилось вносить через страницу деталей эпика. Доски эпиков позволяют визуализировать и просматривать все ваши эпики в одном месте, используя настраиваемый интерфейс с перетаскиванием, который легко сможет освоить любой член команды.

Доски эпиков также будут значительным подспорьем для управления и визуализации идеальных рабочих процессов эпиков, таких как авторство состояний рабочего процесса (Draft, Writing, Done), состояния рабочего процесса DevOps (например, Planned, In Development и In Production) или любые другие взаимоисключающие состояния, которые вы можете моделировать с помощью меток с ограниченной областью действия. Визуализация рабочих процессов с помощью доски эпиков позволит вам повысить предсказуемость и эффективность.

Документация по доскам эпиков и оригинальный эпик.

Встроенный в GitLab реестр модулей Terraform

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure

Модули Terraform играют центральную роль в создании стандартных компонентов инфраструктуры в организации. Вплоть до версии GitLab 13.12 пользователям GitLab приходилось использовать сторонний реестр модулей Terraform, локальные модули или модули, размещаемые в Git. Эти варианты неплохо работают, но они не помогают в распространении модулей, и в них отсутствует надлежащая поддержка версий, что вносит некоторые риски для пользователей этих модулей. GitLab 14.0 добавляет к нашему направлению инфраструктуры как кода реестр модулей Terraform. Теперь вы можете использовать встроенный в GitLab реестр модулей Terraform с поддержкой семантического версионирования для обновления и обслуживания модулей. Более того, вы также можете публиковать модули с помощью GitLab CI/CD.

Поскольку мы используем лучшие практики в работе с Terraform, мы рекомендуем разрабатывать каждый модуль Terraform в отдельном проекте GitLab. Однако для упрощения перехода к реестру пользователи могут размещать и публиковать несколько модулей из одного репозитория GitLab. Вы можете узнать больше о том, как публиковать и использовать модули с реестром модулей Terraform в нашей документации по реестру.

Документация по реестру модулей Terraform и оригинальный тикет.

Обновлённое верхнее навигационное меню

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

В GitLab 14.0 мы обновили и усовершенствовали верхнее меню навигации, которое поможет вам добраться до нужного места быстрее и с меньшим количеством кликов. Это новое объединённое меню совмещает в себе возможности предыдущих меню «Проекты» (Projects), «Группы» (Groups) и «Ещё» (More). Оно обеспечивает доступ к проектам, группам и фичам уровня инстанса всего лишь в один клик. Кроме того, новые отзывчивые элементы улучшают навигацию на небольших экранах.

Тикет для фидбека по обновлённому меню и оригинальный эпик.

Обновлённая боковая навигационная панель

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

GitLab — большое приложение, которое регулярно становится ещё больше. По мере того, как мы представляем новые фичи и категории, навигация по нагруженной контентом левой боковой панели становится менее интуитивной.

В GitLab 14.0 мы переработали дизайн и структуру левой навигационной панели для повышения удобства использования, доступности и похожего опыта использования в разных местах. Мы переместили некоторые ссылки на фичи, разделили фичи меню Операции (Operations) на три отдельных меню, улучшили визуальный контраст и оптимизировали расстояние между пунктами меню, чтобы все они удобно располагались на небольшом экране. Эти изменения нужны для того, чтобы меню лучше соответствовало вашему представлению о жизненном цикле DevOps, а также предоставляло более предсказуемую и привычную навигацию по проектам и группам.

Документация и оригинальный эпик.

Ревью мерж-реквестов в VS Code

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Если вы разработчик, скорее всего, большую часть своего рабочего времени вы проводите в локальной среде разработки. Когда у вас запрашивают ревью мерж-реквеста (в русской локализации GitLab «запрос на слияние»), вам приходится покидать свой редактор и выполнять ревью в GitLab. При проведении ревью в GitLab вам также может понадобиться использовать локальный редактор, чтобы получить больше информации о предлагаемых изменениях.

Версия 3.21.0 расширения GitLab Workflow для Visual Studio Code (VS Code) теперь поддерживает полный процесс ревью мерж-реквестов, включая потоки. Выберите значок GitLab в VS Code, чтобы открыть боковую панель и просмотреть мерж-реквесты для ревью в Merge requests I’m reviewing. Выберите обзор мерж-реквеста, чтобы просмотреть все подробности и текущие обсуждения в мерж-реквесте.

Боковая панель также содержит список всех изменённых файлов в мерж-реквесте. При выборе файла открывается дифф для просмотра изменений в VS Code. Во время просмотра диффа вы можете прочитать комментарии, оставленные к файлам, а также оставить свои комментарии, выбрав номер нужной строки. Все комментарии и отклики, которые вы оставляете в VS Code, будут доступны и в веб-интерфейсе GitLab. Вам будет легче выполнять ревью в VS Code, а другим пользователям — участвовать в этих ревью в GitLab.

Мы действительно счастливы представить полный процесс ревью мерж-реквестов в нашем расширении для VS Code. Откройте тикет и дайте нам знать, что вы думаете по этому поводу.

Документация по расширению GitLab Workflow и оригинальный эпик.

Редактируйте вики-страницы с WYSIWYG редактором Markdown

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Редактирование содержимого вики может быть намного проще! Многие вики-страницы в GitLab используют формат Markdown, и для некоторых пользователей это является препятствием для эффективной совместной работы. В этом релизе у вас появился доступ к современным расширенным возможностям редактирования Markdown в вашей вики, так что вы можете уверенно редактировать вики-страницы.

Мгновенный фидбэк и инструменты визуального редактирования помогают сделать редактирование вики более интуитивным, устранить барьеры и работать совместно. После завершения работы GitLab сохраняет изменения в формате Markdown, поэтому пользователи, которые хотят редактировать Markdown напрямую, могут продолжать это делать. Вы даже можете вводить Markdown в новый редактор, и он будет автоматически форматировать текст по мере ввода.

GitLab 14.0 представляет Редактор контента для вики с поддержкой большинства основных типов контента Markdown, таких как заголовки, жирный текст и курсив, списки, блоки кода и ссылки. Полная поддержка всего GitLab Flavored Markdown specification появится в ближайших релизах. Мы также планируем в будущем сделать этот редактор доступным в других областях GitLab. Мы будем рады услышать мнения об этом MVC в специальном тикете для фидбэка.

Документация по редактору контента для вики и оригинальный эпик.

Идентичные уязвимости DAST собираются в одну уязвимость

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure

В GitLab 13.12 и более ранних версиях все уязвимости DAST, найденные при сканировании, указывались отдельно для каждого URL-адреса, на котором была обнаружена уязвимость. Это могло создавать большое количество однотипных уязвимостей, хотя исправление сводилось к одному файлу или изменению конфигурации. Например, серверный header, отправляемый с каждым HTTP-ответом, вызывал проблему, о которой сообщалось для каждой страницы сайта, а не как об одной проблеме с несколькими вхождениями.

Чтобы уменьшить нагрузку при управлении уязвимостями, GitLab теперь объединяет идентичные уязвимости, найденные на нескольких страницах, в одно сообщение об уязвимости в отчёте DAST. Сведения об уязвимости включают список всех URL, на которых была обнаружена уязвимость, вместо того чтобы создавать для каждой страницы отдельную уязвимость в списке уязвимостей и на панели безопасности.

Это нововведение не будет объединять задним числом уязвимости, найденные в предыдущих сканированиях. Объединение будет работать только с проверками, выполненными в GitLab 14.0 и более поздних версиях.

Документация по отчётам DAST и оригинальный тикет.

Шаблон проекта для управления кластером

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure

В этом релизе мы отказываемся от подхода к управлению кластерами на основе шаблонов CI/CD. Управление кластерами в GitLab — это возможность управлять работой кластеров Kubernetes для повышения доступности приложений, работающих на кластере. Старый метод скрывает слишком много логики, ограничивает настройку и расширение ваших приложений. С новым подходом вы сможете легко создать проект управления кластером из шаблона проекта и получить полный контроль над своими приложениями. Проект, созданный с использованием нового шаблона, содержит код, необходимый для выполнения заданий по управлению кластером, включая встроенную поддержку нескольких приложений. Вы можете легко распространить действие проекта на другие приложения и в полной мере управлять ими.

Кроме того, новые приложения будут устанавливаться с помощью Helm v3. Если вы ранее устанавливали управляемые GitLab приложения с помощью Helm v2, ознакомьтесь с руководством по миграции Helm и инструкцией по миграции управляемых GitLab приложений. Результаты выполнения заданий CI/CD также помогут вам при выполнении этих миграций.

В GitLab 14.0 проект управления кластером поддерживает только интеграцию кластеров на основе сертификатов. Мы планируем добавить поддержку GitLab Kubernetes Agent в следующем релизе.

Документация по шаблону проекта для управления кластером и оригинальный тикет.

Предзаполненный шаблон конвейера в редакторе CI/CD-конвейеров

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Редактор конвейера в GitLab — это ваш универсальный инструмент при взаимодействии с конвейерами (в русской локализации GitLab «сборочные линии») CI/CD. Раньше при написании первого конвейера в редакторе вам предлагалась пустая конфигурация. Это было вполне удобно для опытных разработчиков конвейеров, но для тех, кто только начинает с ними работать, это могло быть немного проблематично.

Начиная с этого релиза, если в проекте не настроен конвейер, редактор загружает шаблон с примером 3-х этапного конвейера. Вы можете сохранить и сразу же запустить этот конвейер, чтобы увидеть его в действии в своём проекте. Кроме того, в шаблоне есть комментарии, которые помогут вам понять синтаксис, а также советы и подсказки, которые помогут начать настраивать шаблон в соответствии с вашими потребностями. Теперь получить первый «зелёный» конвейер стало намного проще!

Документация по редактору конвейера и оригинальный тикет.

Интеграция сканирования контейнеров с Trivy

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Protect

Сканирование контейнеров в GitLab теперь по умолчанию использует движок Trivy. Это изменение предоставит клиентам более своевременные обновления информации об уязвимостях, более точные результаты и поддержку большего числа операционных систем. Пользователи, запускающие сканирование контейнеров с настройками по умолчанию, переключатся на новый движок в GitLab 14.0 автоматически и без каких-либо затруднений. Пользователям, которые настраивают переменные в задании сканирования контейнеров, следует ознакомиться с нашим руководством по переходу и внести необходимые изменения.

Документация по сканированию контейнеров и оригинальный эпик.

Статистика времени внесения изменений через мерж-реквесты на уровне группы

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Release

В рамках нашей работы по добавлению встроенной поддержки метрик DORA4 в GitLab, график времени внесения изменений через мерж-реквесты теперь доступен на уровне группы. Этот релиз продолжает работу, завершённую в GitLab 13.11: теперь вы можете просмотреть график, который показывает, сколько времени требуется мерж-реквестам для развёртывания в продакшене не только в отдельных проектах, но и в целом по группе. Это позволит вам получить полное представление о производительности по проектам группы.

Документация по графикам внесения изменений и оригинальный тикет.

Другие улучшения в GitLab 14.0

Горизонтальная навигация для аналитики цикла разработки на уровне проекта

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Стадии в аналитике цикла разработки на уровне проекта теперь расположены горизонтально. Это помогает визуализировать процесс выполнения работы по стадиям цикла разработки. Кроме того, такой интерфейс совпадает с интерфейсом навигации по аналитике цикла разработки на уровне группы.

Документация по стадиям аналитики цикла разработки](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html#default-stages) и оригинальный тикет.

Улучшенный интерфейс для добавления групп в таблицу DevOps Adoption

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage

Таблица DevOps Adoption даёт информацию о том, как GitLab используется в группах и подгруппах внутри вашей организации. Ранее вы могли добавлять в таблицу не более 200 групп. Мы понимаем, что более крупные организации могут иметь тысячи групп в GitLab. Теперь вы можете использовать поиск в выпадающем списке для добавления любой подгруппы в таблицу.

Кроме того, подгруппы, удалённые из таблицы DevOps Adoption в одной группе, больше не удаляются автоматически из таблиц других групп. В результате миграции данных, которая была проведена для исправления этой проблемы, вам возможно придётся вручную добавить некоторые подгруппы в ваши таблицы при первом повторном посещении их.

Документация по внедрению DevOps и оригинальный тикет.

Использование ключей SSH с истекшим сроком действия по умолчанию отключено

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Ключи SSH с истекшим сроком действия, добавленные в GitLab, теперь отключены по умолчанию. Это помогает сделать ваш инстанс GitLab более безопасным. Ранее ключи SSH с истекшим сроком действия, добавленные в GitLab, были активны по умолчанию, и их можно было использовать, пока администратор их не отключит.

Это изменение влияет на ключи SSH с истекшим сроком действия, используемые на GitLab.com. Если срок действия ваших ключей истёк или скоро истечёт, вам нужно обновить ключ и все использующие его сервисы. Наша документация по ключам SSH содержит полезную информацию о том, как создать новый ключ SSH.

Администраторы инстансов с самостоятельным управлением по-прежнему могут разрешать использование ключей с истекшим сроком действия аналогично тому, как они могут разрешать использование истекших токенов персонального доступа.

Документация по настройкам истечения срока действия ключей SSH и оригинальный тикет.

Отслеживание использования фичи «владельцы кода»

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage

Владельцы кода являются важной частью процесса ревью кода в GitLab. Когда владельцев кода легко определить, пользователи, делающие вклад, могут видеть, кто должен проводить ревью изменений файла или репозитория. Фича «владельцы кода» также может быть использована для настройки процесса подтверждения мерж-реквеста. Теперь вы можете отслеживать, какие команды в вашей организации используют фичу «владельцы кода» в своём процессе разработки.

Если вы хотите внедрить фичу «владельцы кода» в своей организации, отсортируйте таблицу DevOps Adoption по колонке «владельцы кода». Вы увидите команды, которые ещё не используют эту фичу, и поймёте, кому из них нужно помочь начать работать с ней. Вы также можете найти команды, которые уже успешно настроили фичу «владельцы кода», и получить от них полезные советы и фидбек. Таблица DevOps Adoption доступна на уровне группы и на уровне инстанса.

Документация по внедрению DevOps и оригинальный тикет.

Уведомления в Slack при редактировании вики включают ссылки на файлы диффа

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Наш сервис уведомлений в Slack может сообщать вам, когда пользователь редактирует одну из страниц вики. Сообщение в Slack предоставит вам полезный контекст изменения, включая проект, имя страницы и сообщение коммита. Однако иногда сообщение коммита не даёт достаточно контекста, и вам нужно больше информации о том, какие изменения были внесены.

Теперь вы можете нажать кнопку Сравнить изменения (Compare changes) в сообщении в Slack, чтобы сразу перейти к диффу. Это позволит сэкономить время и снизить уровень непонимания при двусмысленных или неполных сообщениях коммита.

Документация по триггерам уведомлений в Slack и оригинальный тикет.

Обработчик заданий GitLab 14.0

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Мы также выпускаем новую версию обработчика заданий GitLab — 14.0! Обработчик заданий GitLab — это легковесный, высокомасштабируемый агент, который выполняет ваши задания сборки и отправляет результаты обратно в инстанс GitLab. Обработчик заданий GitLab работает вместе с GitLab CI/CD — сервисом непрерывной интеграции с открытым кодом, поставляемым с GitLab.

Что нового:

• Возможность сделать pwsh (PowerShell Core) оболочкой по умолчанию для новых регистраций обработчиков заданий под Windows
• Вспомогательный образ обработчика заданий с Ubuntu

Исправления ошибок:

• PowerShell нельзя было использовать с флагом FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY, установленным в false
• В исполнителе shell постоянно блокировалась подпрограмма Go
• Причина ошибок job_canceled могла быть отправлена в Rails, что приводило к ошибке с кодом 500
• Обработчик заданий Gitlab не мог обработать URL Gitlab при развёртывании в Kubernetes

Список всех изменений обработчика заданий GitLab здесь.

Документация по обработчику заданий GitLab.

Предопределённые переменные CI/CD для действий окружения

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Если вы хотите использовать одни и те же скрипты и настройки в разных заданиях развёртывания при помощи ключевого слова environment:, вам может быть сложно исключить определённые шаблоны поведения на основе типа действия, которое выполняет задание развёртывания. Например, действие окружения stop может быть заданием, которое останавливает review_app, и вы не хотите, чтобы запускались ваши скрипты развёртывания.

Теперь значение environment: action: доступно как предопределённая переменная CI/CD CI_ENVIRONMENT_ACTION, что максимально упрощает настройку скриптов для работы во всех заданиях развёртывания.

Документация по предопределённым переменным и оригинальный тикет.

Установка пакетов PyPI из группы или подгруппы

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package

Вы можете использовать реестр пакетов вашего проекта, чтобы публиковать и устанавливать пакеты PyPI. При установке пакета PyPI вы должны указать, в каком проекте находится пакет. Это отлично работает для небольшого числа проектов, но если у вас есть несколько проектов в группе, вам, возможно, придётся добавлять десятки и даже сотни разных источников.

В крупных организациях с большим числом команд разработчики часто публикуют пакеты в реестры пакетов их проекта вместе с исходным кодом и конвейерами. Однако они также должны иметь возможность легко устанавливать зависимости из других проектов внутри организации. Теперь вы можете устанавливать пакеты из своей группы, так что вам не придётся запоминать, в каком проекте находится каждый пакет. Просто задайте путь к пакету, используя простой API: GET groups/:id/packages/pypi/files/:sha256/:file_identifier.

Вы также можете записывать результат выполнения в файл или вернуть дескриптор пакета как HTML-файл. Посмотрите документацию, чтобы получить больше информации, и дайте нам знать, что у вас получается. Мы надеемся, что это сделает работу вашей команды и организации более эффективной.

Документация по установке пакетов PyPI на уровне группы и оригинальный тикет.

Обобщённые детали в отчёте по безопасности

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure

Автоматизированное сканирование безопасности является важной частью любого безопасного процесса разработки. Существует большое число инструментов и технологий, покрывающих SDLC, начиная от сканирования исходного года, и заканчивая сканированием приложений и инфраструктуры после развёртывания. Конечная цель всех этих инструментов — обнаружить известные и потенциальные уязвимости, но информация от разных сканеров может значительно отличаться. Попытки стандартизировать данные результатов сканирования существуют, но они обычно фокусируются только на одной технологии сканирования или даже определённом наборе инструментов. Это представляет большую сложность для команд безопасности, которым нужно собирать широкий разброс результатов сканирований. Без надёжного способа нормализовать разрозненные данные очень сложно просматривать уникальные детали результатов сканирования для каждого сканера. И если выходные данные инструментов не собираются в одном месте, они обычно просматриваются в исходном инструменте. В результате реальная картина риска уязвимостей становится фрагментированной и остаётся вне цепи инструментов DevOps.

Новая структура с обобщёнными деталями в наших схемах отчётов по безопасности может сократить этот разрыв. Вы уже можете интегрировать широкий круг сканеров безопасности в GitLab с минимальными усилиями. Теперь вы можете продвинуться ещё дальше за счёт богатого набора опций форматирования для поиска деталей. Наша новая структура позволяет легко отображать существующие выходные данные большинства инструментов в наши форматы отчётов JSON, при этом автоматически добавляя последовательную логику презентации. Гибкость без потери возможности обеспечить большое число данных об уязвимостях — главная цель новой структуры. Детали предоставляются в открытой структуре с использованием предопределённых типов данных. Предопределённые типы обеспечивают и валидацию данных, и стандартизированное представление пользовательского интерфейса в GitLab. Например, мы предоставляем такие типы данных: целое число, ссылка, таблица и даже маркдаун GitLab (GFM). Это предоставляет точный контроль над тем, как отображаются детали, и при этом сохраняет согласованность общего опыта работы с GitLab.

Документация по уязвимостям и оригиральный тикет.

Отдельная страница для списков пользователей, использующих переключаемые фичи

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release

Ранее, чтобы получить доступ к спискам пользователей переключаемых фич (feature flags), вам приходилось переходить на отдельную вкладку под страницей переключаемых фич. Такой интерфейс не отражал сути отношений между переключаемыми фичами и списками пользователей, так как списки пользователей являются дочерней фичей переключаемых фич. В этом релизе мы перенесли списки пользователей на отдельную страницу в разделе переключаемых фич, что улучшает рабочий процесс и более точно показывает отношения между ними.

Документация по спискам пользователей переключаемых фич и оригинальный тикет.

Динамическое обновление таймера соглашения об уровне сервиса для инцидентов

(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor

Таймер соглашения об уровне сервиса для инцидентов, представленный в GitLab 13.5, показывает время, оставшееся до нарушения соглашения для инцидентов. Однако ранее пользователям нужно было обновлять страницу, чтобы обновить значение таймера. Начиная с GitLab 14.0 таймер обновляется динамически каждые 15 минут без необходимости обновлять страницу.

Документация по таймеру соглашения об уровне сервиса для инцидентов и оригинальный тикет.

Управление нагрузкой базы данных доступно в Free

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Доступность

Управление нагрузкой базы данных позволяет распределять запросы на чтение между несколькими серверами. Для инстансов GitLab с тысячами пользователей распределение запросов может снизить нагрузку на основную базу данных и повысить скорость ответа, что приведёт к более быстрой загрузке страниц внутри GitLab.

В этом релизе мы переместили распределение нагрузки из Premium в Free, что позволит большему числу пользователей воспользоваться этой фичей.

Документация по управлению нагрузкой базы данных и оригинальный тикет.

Поддержка Geo для высокой доступности PostgreSQL в общем доступе

(self-managed: PREMIUM, ULTIMATE) Доступность

Patroni — это решение для обеспечения высокой доступности PostgreSQL, которое также позволяет настраивать высокодоступный резервный кластер PostgreSQL на вторичной ноде Geo. Эта конфигурация пригодится, когда вторичная нода используется как часть стратегии аварийного восстановления, поскольку позволяет системным администраторам зеркалировать количество нод базы данных на первичной и вторичной нодах. Это означает, что после сбоя не потребуется дополнительных нод базы данных для восстановления высокой доступности.

Geo теперь предоставляет общедоступную поддержку для высокодоступных конфигураций PostgreSQL через Patroni.

Мы улучшили документацию, обновили версию Patroni до 2.0.2, добавили поддержку распределения нагрузки базы данных на резервных кластерах и убедились, что команды приостановки и возобновления заданий по репликации работают с резервным кластером Patroni.

Документация по поддержке Patroni и оригинальный эпик.

Обновление Ruby on Rails до версии 6.1

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Доступность

В этом релизе мы обновили Ruby on Rails до версии 6.1, чтобы вы могли воспользоваться всеми преимуществами последних улучшений этого фреймворка для разработки приложений. Посмотрите примечания к релизу Ruby on Rails 6.1, чтобы узнать больше подробностей.

Документация по Gemfile, оригинальный тикет и оригинальный эпик.

Шкала производительности показывает процент используемой памяти

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Доступность

Шкала производительности позволяет системным администраторам и разработчикам ПО оценить производительность страницы GitLab.

Разработчикам ПО важно иметь наглядное представление используемой памяти, чтобы они могли улучшить производительность и впечатления от использования GitLab. В этом релизе мы добавили поле памяти, которое отображает количество используемой памяти и выделенные объекты для текущего запроса. При выборе этого поля отображается дополнительная информация. Эта информация поможет разработчикам быстрее замечать проблемы с использованием памяти и разрабатывать более эффективные и производительные фичи.

Документация по шкале производительности и оригинальный тикет.

Редизайн панели сайтов Geo

(self-managed: PREMIUM, ULTIMATE) Доступность

Geo реплицирует и верифицирует множество разных типов данных. Системным администраторам нужно следить за состоянием сайтов Geo, чтобы знать, есть ли на них проблемы, требующие внимания, например, несинхронизованные проекты или несовпадения контрольных сумм. В нашем исследовании пользовательского опыта мы выяснили, что администраторам, использующим страницу администратора Geo, часто было сложно находить нужную информацию, и отображаемая информация могла быть непонятной. Наш редизайн панели сайтов Geo исправляет эти проблемы. Мы добавили больше полезных индикаторов, таких как сводка по синхронизации и верификации типов данных и полоска статуса верификации для отдельных типов данных. Мы также улучшили структуру страницы, снизив число нажатий, необходимое для получения нужной информации.

Документация по настройке Geo и оригинальный эпик.

Идентификация выделенных пользователей на уровне группы

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

В этом релизе мы добавили возможность идентифицировать выделенных (provisioned) пользователей и разработчиков. Напротив выделенных пользователей будет отображаться новая метка Enterprise. Это поможет пользователям отличать аккаунты, которые группа создаёт автоматически через SCIM, от аккаунтов, созданных пользователями вручную.

Документация по настройке SCIM и оригинальный тикет.

Отчёт о внедрении DevOps на уровне экземпляра включён по умолчанию

(self-managed: ULTIMATE) Стадия цикла DevOps: Manage

Отчёт о внедрении DevOps на уровне экземпляра теперь по умолчанию включён. Отчёт DevOps Adoption показывает, какие команды в вашей организации используют в GitLab:

• тикеты
• мерж-реквесты
• подтверждения
• обработчики заданий
• конвейеры
• развёртывания
• сканирования

Сравните внедрение GitLab во всей организации, добавив группы в таблицу внедрения. Вот лишь несколько способов использования отчёта DevOps Adoption:

• Проверьте, получаете ли вы ту отдачу от вложений, которую ожидали от GitLab.
• Определите конкретные группы, которые медленнее внедряют GitLab, чтобы помочь им в их пути к DevOps.
• Определите группы, которые внедрили определённые фичи, например конвейеры, и дайте советы другим группам, заинтересованным в начале работы с этими фичами.

Это — только начало, вас ждёт ещё немало фич, которые помогут измерить внедрение DevOps в вашей организации и оценить его преимущества. В соответствующем эпике вы сможете узнать о следующих дополнениях.

Отчёт о внедрении DevOps также доступен на уровне группы. Пользователи SaaS могут получить полезные идеи о внедрении для всей организации, просмотрев отчёт о внедрении DevOps в своей группе верхнего уровня.

Документация по DevOps Adoption и оригинальный тикет.

Установка местоимений в профилях пользователей GitLab

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

В профили пользователей GitLab были добавлены местоимения. Они будут отображаться рядом с именами пользователей на вкладке Профиль (Profile). Вы можете:

• решить, нужно ли добавлять местоимения в профиль;
• самоидентифицироваться и ввести любые местоимения, которые вы предпочитаете, без выбора из заранее определённого списка.

Помимо большей инклюзивности, GitLab хочет помочь людям использовать правильные местоимения при ответах на комментарии, чтобы уважать личности друг друга.

Документация по добавлению личных местоимений и оригинальный тикет.

Редактирование имени проекта и пути по умолчанию при форке

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Форк проекта позволяет получить точную копию исходного репозитория, в котором вы можете экспериментировать, применять изменения и вносить вклад в родительский проект. У ваших форков должны быть осмысленные имена, объясняющие их цели, и если ваш проект расходится и дальше, вам может потребоваться несколько форков одного проекта.

С этого релиза GitLab поддерживает редактирование имени проекта и семантического URL проекта непосредственно при создании форка. Теперь вы можете создать несколько форков с разными именами одного и того же проекта в одной группе!

Документация по созданию форков и оригинальный тикет.

Теперь можно использовать символ ~ для маскирования переменных CI/CD

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Безопасное управление секретными ключами, хранящимися в переменных CI/CD, крайне важно. Вы можете скрыть значения переменных в журналах заданий, замаскировав переменные, но GitLab поддерживает в этой роли только определённые символы. Теперь мы поддерживаем маскирующие переменные с символом ~ в значении, что расширяет фичу для поддержки большего количества ключей, генерируемых другими платформами поставщиков секретных ключей. Спасибо dallmair из нашего сообщества за этот вклад!

Документация по маскированию переменной CI/CD и оригинальный тикет.

Определяйте, какие задания запускали нижестоящие конвейеры

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Раньше, глядя на представление конвейера, было трудно определить, какое задание запустило нижестоящий конвейер. Начиная с версии 14.0, каждый нижестоящий конвейер показывает имя задания, которое его запустило. Это упрощает отслеживание потока выполнения в сложных конвейерах, запускающих нисходящие конвейеры.

Документация по вложенным конвейерам и оригинальный тикет.

Удаление связанных файлов пакета через пользовательский интерфейс

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package

Реестр пакетов GitLab используется для публикации, установки и совместного использования зависимостей. Когда вы публикуете зависимость, она генерирует несколько файлов, включая архив пакета. До GitLab 14.0 для удаления таких файлов приходилось использовать API. В GitLab 14.0 теперь вы можете использовать пользовательский интерфейс, чтобы удалить как файлы, связанные с данным пакетом, так и сам пакет.

Поскольку содержать реестр в порядке может быть непросто, наша цель — упростить и повысить эффективность этого процесса, добавив дополнительные параметры для удаления неиспользуемых файлов.

Документация по удалению файлов, связанных с пакетом и оригинальный тикет.

Закрепление конкретных версий анализатора SAST

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

С развитием инструментов сканирования GitLab Secure нам потребовалось повысить степень детализации нашего процесса подготовки релиза. Ранее GitLab использовал общие мажорные версии для всех наших анализаторов и инструментов. Для этого нужно было, чтобы все инструменты были одной и той же мажорной версии, что не давало использовать семантическую нумерацию версий. Начиная с версии 14.0 мы убрали глобальную переменную SAST_ANALYZER_IMAGE_TAG в нашем шаблоне SAST.gitlab-ci.yml в пользу переменной задания анализатора, устанавливающей тег major.minor в поставляемом шаблоне SAST. Каждое задание анализатора теперь имеет свою переменную SAST_ANALYZER_IMAGE_TAG, которой будет управлять GitLab, и для неё будет установлен тег major для соответствующего анализатора. Чтобы закрепить определённую версию, просто измените значение переменной на конкретный тег версии.

Если вы переопределяете или поддерживаете пользовательские версии SAST.gitlab-ci.yml, вам надо будет обновить свои шаблоны CI, чтобы перестать ссылаться на глобальный SAST_ANALYZER_IMAGE_TAG и перейти к использованию соответствующего тега задания анализатора с нужной областью видимости. Мы настоятельно рекомендуем наследовать и переопределять управляемые GitLab шаблоны CI, чтобы ваши шаблоны CI не ломались в будущем. Это изменение позволит вам более детально контролировать будущие обновления анализатора с помощью закреплённой версии major.minor.

Документация по закреплению версии анализатора и оригинальный эпик.

Обновления анализаторов SAST

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

SAST (Статическое тестирование безопасности приложений) в GitLab включает в себя множество анализаторов безопасности, которые команда статического анализа GitLab активно поддерживает и обновляет. Ниже представлены обновления анализаторов, выпущенные в релизе 14.0. Эти обновления включают расширенное покрытие, исправления ошибок и другие улучшения.

• Semgrep обновлён до версии 2.8.0: мерж-реквест, список изменений * Исправили неправильные номера строк для многострочного универсального режима * SAST_EXCLUDED_PATHS передаются в semgrep для исключения при запуске semgrep * Оптимизировали производительность * К первичному идентификатору правила в отчёте добавили URL, чтобы связать его с базовым правилом
• GoSec обновлён до версии 3.1.0: мерж-реквест, список изменений * Убрали поддержку SAST_GOSEC_CONFIG, уведомление об устаревании * Добавили переменную COMPILE для поддержки пропуска получения зависимостей при желании * Добавили переменную GOSEC_GO_PKG_PATH чтобы дать возможность указать, где go собирает приложение * Обновили получение зависимостей, чтобы по умолчанию только загружать пакеты, а не собирать или устанавливать
• Flawfinder обновили до версии 2.0.17: мерж-реквест, список изменений
• SpotBugs обновили до версии 2.28.3 мерж-реквест, список изменений * Обновили зависимости
• PMD-Apex обновили до версии 2.12.3: мерж-реквест, список изменений * Повысили точность правил, исправили баги
• ESLint обновили до версии 7.27.0: мерж-реквест, список изменений * Обратите внимание, этот анализатор планируется заменить на Semgrep в одном из следующих релизов.

Если вы используете поставляемый GitLab шаблон SAST (SAST.gitlab-ci.yml), вам не нужно ничего делать, чтобы получить эти обновления. Однако, если вы переопределяете его или используете свой собственный шаблон CI, вам потребуется обновить конфигурации CI. Если вы хотите использовать определённую версию любого анализатора, теперь вы можете закрепить минорную версию анализатора. Закрепление одной из предыдущих версий отменит автоматические обновления анализатора и потребует от вас вручную менять версию анализатора в шаблоне CI.

Документация по настройке анализаторов SAST и оригинальный тикет.

Изменение типа тикета

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor

Иногда может понадобиться изменить тип тикета. Например, вы можете захотеть поднять его уровень до инцидента, чтобы убедиться, что ваша команда корректно обработает проблему. Чтобы изменить тип тикета, начните редактировать его и выберите тип из меню Issue type.

Документация по изменению типа тикета и оригинальный тикет.

Интеграция сканирования контейнеров с Grype

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Protect

Сканирование контейнеров GitLab теперь может использовать движок сканирования Grype вместо Trivy, применяемого по умолчанию. Это даёт пользователям больше гибкости в выборе движка для сканирования контейнеров. Мы сравнили эти два сканера с открытым исходным кодом. Однако, поскольку каждый сканер уникален, вы можете сравнить сами, чтобы решить, какой из них лучше для вас. Пользователи могут попробовать сканер Grype, установив переменную CI CS_ANALYZER_IMAGE: registry.gitlab.com/security-products/container-scanning/grype:4.

Документация по выбору движка сканирования и оригинальный тикет.

Geo требует подтверждения перед повторной синхронизацией всех проектов

(self-managed: PREMIUM, ULTIMATE) Доступность

В пользовательском интерфейсе Geo Admin есть кнопка Повторно синхронизировать все проекты (Resync All). Для клиентов с большим количеством проектов, пытающихся повторно синхронизировать только проблемные репозитории, непреднамеренное включение этой опции может вызвать значительные задержки в устранении неполадок. Теперь мы отображаем модальное окно подтверждения всякий раз, когда выбрано Resync All. Это небольшое, но эффективное улучшение UX снижает вероятность того, что администраторы случайно запустят повторную синхронизацию всех своих проектов.

Документация по администрированию Geo и оригинальный тикет.

Улучшения GitLab chart

(self-managed: FREE, PREMIUM, ULTIMATE) Доступность

• В GitLab 14.0 минимальная версия Kubernetes должна быть 1.16.
• Ранее в развёртывании сервера агентов Kubernetes (KAS) не было возможности указать imagePullSecret. Это приводило к отказу из-за ошибки авторизации. Теперь, когда pullSecrets присутствует, получение образа происходит успешно, и поды запускаются.
• GitLab 14.0 обновляет Cert Manager до версии 1.2.0.
• GitLab 14.0 обновляет Grafana chart до версии 6.9.1. Развёрнутые с помощью чартов фичи Grafana теперь сравнялись с Omnibus (в версии 7.5.5) и решают проблему с устареванием.

Документация по GitLab chart.

Место хранения проекта доступно в API REST и GraphQL

(self-managed: FREE, PREMIUM, ULTIMATE) Доступность

После появления хэшированного хранилища стало труднее понять, где реально хранится проект. Системные администраторы могли искать путь в пользовательском интерфейсе администратора проекта, но для многих проектов это было непрактично. В этом релизе мы добавили конечные точки API, которые предоставляют информацию о хранении проекта. В REST API этой новой конечной точкой является GET /projects/:id/storage. Для GraphQL поле diskPath теперь доступно в объекте Repository.

Документация по получению пути хранения проекта и оригинальный эпик.

Исправленные баги

Вот некоторые баги, которые мы исправили в релизе 14.0, и о которых стоит упомянуть:

• Статус правил очистки может зависнуть в состоянии «ongoing»
• Фильтр активности в отчёте об уязвимости выдавал ошибку на панели мониторинга на уровне группы
• Фильтр сканера на вкладке безопасности конвейера не фильтровал результаты
• Вводящая в заблуждение ошибка «Dockerfile не найден» при сканировании контейнера
• Не работали ежедневные обновления сканирования контейнеров
• График cilium 1.8.1 работал некорректно в последних версиях GKE
• Общая панель поиска с фильтрами не позволяла выбирать несколько меток
• Аналитика цикла разработки: Невозможно было добавить новый фильтр меток после удаления предыдущего
• Аналитика цикла разработки: постоянный этап по умолчанию не мог быть удалён или отредактирован
• Всплывающая подсказка по внедрению DevOps показывала неверные данные
• Аналитика производительности: график линии тренда не загружался, так как n.response не был определён
• Фильтрация меток не работала для интеграции уведомлений Slack
• Запрос diffs_metadata возвращал ошибку 500
• Невозможно было редактировать мерж-реквест с непроверенным состоянием возможности мержа
• Невозможно было просмотреть старые версии мерж-реквестов
• «Запрет одобрения мерж-реквеста его автором» работал, только если установить, сохранить и отменить
• Письма с уведомлением об истечении срока действия ключа SSH не отправлялись, если срок действия истёк в прошлом
• Индексация проектов зависала и тратила много ресурсов
• Ссылка на мерж-реквест в результатах глобального поиска была неправильной
• Кнопка «Отменить конвейер» показываетсь пользователям, которые не могли её нажимать
• Ограничение «только внешние пулл-реквесты» ( only: … external_pull_requests в файле gitlab-ci.yml) не работало
• Использование необязательных требований (needs) вызывало ошибку рендеринга в представлении конвейера
• Теперь используется правильный URL Gitpod в пользовательских настройках для инстансов с самостоятельным управлением
• Исправлено задание Rake gitlab:incoming_email:check после изменений в 13.12
• Удалён лишний символ из поля описания в экспорте требований
• Письма от службы поддержки при использовании неуникального суффикса проекта теперь не отклоняются
• Исправлены некоторые фильтры, которые не работали со списками досок GraphQL
• GraphQL EpicsResolver не обрабатывал аргументы timeframe
• Переключатель уведомлений не мог быть включён для проектов, для которых он ранее мог быть включён
• Mermaid-диаграмма stateDiagram-v2 с описанием состояния не отображалась
• Была задержка в обновлении значков открытого мерж-реквеста и количества тикетов на вторичной ноде Geo

Посмотрите все исправления багов в GitLab 14.0

Улучшения удобства использования

В каждом релизе мы работаем над повышением общей эффективности и полезности нашего продукта.

У нас также есть Галерея UI Polish для отслеживания важных обновлений наших интерфейсов. Эти обновления, хоть часто и небольшие, заметно улучшают удобство использования.

В GitLab 14.0 мы поработали над тикетами, проектами, майлстоунами и многим другим! Мы особо выделяем следующие изменения в GitLab 14.0:

• Аналитика обзора группы: заменили карточку метрик одной статистикой.
• Теперь показываются хэши, связанные с пакетом.
• Кнопка «Start/Add Merge Train» делается красной, если последний конвейер в мерж-реквесте не прошёл.

Посмотрите все улучшения удобства использования в GitLab 14.0.

---

Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте: 14.0 released with a celebration of GitLab 14.

Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.