[Перевод] Вышел долгожданный релиз 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, повышают эффективность совместной работы.
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.
Что нового:
Исправления ошибок:
Список всех изменений обработчика заданий 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
