Новый релиз 12.2 поможет вам оптимизировать конвейеры, улучшить качество совместной работы и наладить внутренние зависимости между проектами. Читайте дальше, чтобы узнать все о новых фичах в 12.2.
Цель CI/CD конвейеров — автоматизация ручных заданий сборки и тестирования и ускоренная поставка ПО при снижении количества ошибок. Но в некоторых случаях конвейеры в GitLab не так эффективны, как хотелось бы. С релизом 12.2 мы вводим новый метод создания и управления для сложных зависимостей между заданиями — направленные ациклические графы — вместо старого варианта, где вам требовалось полагаться на выполнение последовательных этапов. Новый способ по-настоящему мощный, он ускорит работу ваших конвейеров и сделает их более эффективными.
Разработка ПО — командный спорт, и мы делаем все для того, чтобы вносить свой вклад было проще и удобнее для каждого. С релизом 12.2 мы добавляем управление дизайном в GitLab, предоставляя дизайнерам удобный инструмент для совместной работы и управления версиями дизайна ваших проектов в одном месте.
Это только начало нашей работы над рабочими процессами для дизайнеров в GitLab, и мы будем рады, если вы также внесете свой вклад в нашу стратегию управления дизайном.
Сложные системы часто включают в себя несколько проектов с внутренними зависимостями между изменениями кода, так что последовательность мержа изменений имеет значение. Теперь GitLab поддерживает межпроектные зависимости мерж-реквестов, предоставляя возможность задавать отношения этих зависимостей и помогая избежать ошибок из-за мержа изменений в неправильном порядке. Меньшее число ошибок приведет к более быстрому деплою ваших изменений.
В релизе 12.2 так много классных фич, что мы никак бы не смогли рассказать в обзоре обо всех. Вот еще несколько улучшений из этого релиза: ограничение членства в группе по домену, стратегии выпуска обновлений по проценту или ID пользователей для переключаемых фич, подтверждение безопасности мерж-реквеста и перенос ограниченных переменных окружения в план Core. Читайте далее, чтобы узнать об этих фичах подробнее.
Зарегистрируйтесь и принимайте участие в наших первых конференциях в Лондоне и Бруклине Приглашаем на наши встречи
Вклад Fabio в релиз 12.2 добавляет новую настройку, которая позволяет пользователям с правами maintainer создавать подгруппы, что ранее могли делать только пользователи с правами owner. Также он добавил ценные изменения в релизы GitLab 11.10 и GitLab 12.0. Огромное спасибо Fabio за эту работу!
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
В простых случаях все задания одного этапа на конвейере должны завершиться прежде, чем будет начат следующий этап. Для многих конвейеров сначала должны успешно пройти все тесты, а затем уже начнется деплой. Но в более сложных случаях вам может потребоваться, чтобы задания следующего этапа были запущены раньше, чем завершится предыдущий этап. Например, у вас есть проект, который собирает версию приложения под Android и iOS на многоэтапном конвейере. Скорее всего, вы захотите, чтобы разворачивание приложения для конкретной платформы началось как только тесты для неё будут успешно пройдены, — ждать результатов тестов для другой платформы совсем не обязательно. Общее время обработки может остаться тем же, но вот реальное время выполнения конкретной задачи может сократиться.
Именно для подобных ситуаций мы добавили новый мощный и гибкий инструмент — ключевое слово needs:
в файле .gitlab-ci.yml
для определения взаимоотношений ваших заданий. С помощью этого ключевого слова вы можете задать одно задание как необходимое для выполнения другого. Как только необходимое задание будет выполнено, зависящее от него задание со следующего этапа будет запущено сразу же, не дожидаясь выполнения всего этапа. Мы добавили эту возможность в GitLab с помощью направленных ациклических графов (Directed Acyclic Graph). При создании конвейера из вашей конфигурации GitLab использует сложный набор правил, определяющий последовательность выполнения заданий, вместо того, чтобы откладывать задания следующего этапа до завершения текущего.
Теперь работа конвейеров станет более эффективной, и в дальнейшем вас ждут еще более продвинутые возможности управления ими. Пока же мы предлагаем вам начать использовать ключевое слово needs
для создания конвейеров как в примере выше или для случаев, где несколько несвязанных сервисов находятся в одном монорепозитории и не обязаны ждать сборку друг друга.
</div>
Документация по направленным ациклическим графам и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Аннотации для дизайнов дают возможность дизайнерам и разработчикам более тесно работать вместе над дизайнами за счет комментариев, которые можно оставлять к конкретным местам. Мы продолжаем повышать ценность задач, как главного источника информации в GitLab, добавив работу над дизайном в задачах, и в то же время предоставляем удобный способ оставлять фидбек о дизайнах.
Это только начало нашей работы над рабочими процессами для дизайнеров в GitLab, и мы будем рады, если вы также внесете свой вклад в нашу стратегию управления дизайном.
Управление дизайном на данный момент работает в альфа версии, и его поведение может быть в любой момент изменено. Также управление дизайном требует подключения LFS (Large File Storage).
Документация по управлению дизайном, оригинальные тикет и эпик.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Компании, которые поставляют несколько связанных продуктов, часто используют в них общие сервисы и библиотеки, которые хранятся как отдельные проекты. Но это усложняет координацию изменений между сервисами и их пользователями, особенно, если фича требует изменений в нескольких компонентах.
Начиная с релиза 12.2 вы можете обезопасить себя от мержа таких изменений в неправильном порядке, задав необходимые отношения с помощью межпроектных зависимостей для мерж-реквестов. Эта фича также поможет вам сделать такие зависимости более явными для тех, кто будет проводить ревью изменений.
Документация по зависимостям мерж-реквестов и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Для организаций, уделяющих много внимания безопасности, важным аспектом управления рисками является контроль над тем, кто имеет доступ к проектам и группам. В релизе 12.2 мы добавляем дополнительный инструмент для администраторов и владельцев групп, позволяющий предоставлять доступ к членству в группе только пользователям с email-адресом, принадлежащим конкретному домену.
Таким образом, ваша компания YourCompany (к примеру) может установить доступ к группе только пользователям, использующим email-адрес на домене yourcompany.com, и владельцы не смогут случайно добавить в группу пользователей вне организации.
Документация по ограничению доступа по домену и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Теперь вы можете выбрать стратегию выпуска обновлений “Percentage Rollout” (по проценту пользователей) для ваших переключаемых фич. Конкретный процент можно задать для каждого окружения и каждой фичи; когда вы выбираете этот способ выпуска обновлений, ваша фича появится у заданного процента вошедших пользователей. Таким образом, вы сможете контролируемо выпускать обновления, отслеживая поведение целевого окружения на предмет того, совпадают ли результаты с ожидаемыми.
Документация по стратегиям выпуска обновлений и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Теперь вы можете выбрать стратегию выпуска обновлений “User ID” (по ID пользователей) для ваших переключаемых фич. Вам потребуется указать список ID, разделенных запятыми, и ваша фича будет подключена только для указанных пользователей. Таким образом, вы сможете протестировать фичи на определенных сегментах вашей базы пользователей.
Документация по целевым пользователям переключаемых фич и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Теперь вы можете быть уверены, что мерж-реквесты, в которых найдены новые уязвимости, не будут смержены, пока назначенные люди не проведут ревью и не подтвердят изменение. Это позволит вам и вашим командам проще следовать политике безопасности, а также гарантирует, что новые уязвимости не попадут в вашу базу кода без явного подтверждения.
Документация по утверждению безопасности в мерж-реквестах и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Теперь при запуске задания вручную стало возможным переопределять или задавать новые переменные для этого задания. Это позволит проще создавать настраиваемые пользовательские и/или повторяющиеся задания как часть ваших конвейеров, а также упростит поиск проблем при выполнении заданий.
Документация по определению переменных при запуске заданий с ручным управлением и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Изначально представленная в GitLab Premium 9.4 возможность ограничивать переменные окружения в определенных окружениях теперь перемещена в план подписки GitLab Core. Эта фича дает больше гибкости при конфигурации различных переменных (например, закрытых ключей доступа к разным частям инфраструктуры окружения) и использовании нескольких окружений в жизненном цикле разработки.
Мы делаем код этой фичи открытым в соответствии с нашей политикой клиентоориентированности, чтобы вдохновить вас на ее использование и на дальнейшие вклады в разработку.
Документация по ограничению переменных окружения и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Реестр NPM GitLab позволяет разработчикам Javascript собирать, публиковать и редактировать пакеты NPM через инстанс GitLab. NPM требует от пользователей аутентификации через OAuth, а до версии 12.2 GitLab не поддерживал ее. Пользователям приходилось генерировать свой собственный токен за пределами GitLab для того, чтобы пользоваться реестром NPM, что также не давало им пользоваться двухфакторной аутентификацией. Это решение не подходит для наших пользователей, так как не является масштабируемым.
Мы с радостью объявляем, что начиная с версии 12.2 мы поддерживаем аутентификацию с помощью личных токенов доступа GitLab. Личные токены доступа GitLab безупречно работают с двухфакторной аутентификацией и позволяют пользователям выбирать объем и политику истечения срока действия, которые подходят для них. Просто обновите свой файл .nprmrc с вашим личным токеном доступа и начинайте публиковать и скачивать пакеты через реестр NPM GitLab.
Документация по аутентификации при помощи токена OAuth и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Использование звезд — это распространенный способ отмечать понравившиеся проекты. Благодаря вкладу сообщества теперь стало возможным просматривать список пользователей, которые отметили проект звездой, через пользовательский интерфейс, кликнув на число отметивших на странице проекта. Этот список также доступен через API проектов.
Проекты, отмеченные звездой, также можно просматривать в профиле пользователя.
Спасибо Camil Staps за эту фичу!
Документация по профилю пользователя и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Для крупных организаций, у которых гибкость в приоритете, подгруппы — это ценный инструмент для сохранения структуры инстанса по мере того, как он растет. Теперь мы добавляем возможность пользователям с правами Owners давать Maintainers разрешение на создание подгрупп. Когда эта опция включена, Maintainers смогут быстро и независимо работать с группой без необходимости запрашивать вмешательство Owners для сохранения структуры проектов.
Спасибо Fabio Papa за эту фичу!
Документация по созданию подгрупп и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
GitLab уже поддерживает открытие мерж-реквеста и отправку его на мерж при успешном завершении конвейера с помощью опций команды Git push. Это позволяет легко и быстро мержить небольшие изменения.
В релизе 12.2 GitLab научился новым опциям пуша:
Документация по настройкам пуша git и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
При просмотре диффа большинство неизмененных строчек скрыты, чтобы можно было быстро просматривать изменения. Однако иногда для понимания изменений необходимо больше контекста. В GitLab 12.2 скрытые строчки теперь можно разворачивать полностью или пошагово. Ранее скрытые строчки можно было разворачивать только пошагово и снизу вверх.
Документация по пошаговому разворачиванию диффа и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Пользователи уже могут изменять метки для нескольких тикетов одновременно в пределах конкретного проекта. В версии 12.2 мы добавляем возможность массово редактировать метки тикетов на уровне группы, что упрощает управление метками.
Документация по массовому редактированию и оригинальный тикет.
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Часто бывает неочевидно, кто должен производить ревью предложенных вами изменений. Назначение владельцев кода для отдельных файлов упрощает это распределение обязанностей. Как только владелец кода назначен, его можно увидеть при просмотре файла и автоматически назначить ответственным за принятие мерж-реквеста.
В GitLab 12.2 помимо назначения владельцев кода по имени пользователя GitLab и по email, вы также сможете назначать группы владельцами кода. Это поможет владельцам кода не выпадать из работы при смене команд, особенно при использовании LDAP для управления групповыми учетными записями.
Документация по владельцам кода и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
С информацией о том, кто последний изменил строку кода и как именно, можно обратиться к нужному человеку и внести соответствующие изменения. Команда Git blame
упрощает поиск этой информации.
В GitLab 12.2 новый API команды Blame позволяет получать эту информацию напрямую из GitLab без необходимости скачивать репозиторий. Это пригодится для написания скриптов и автоматизации на основе информации о пользователях, которые недавно изменяли файл.
Спасибо Oleg Zubchenko за эту фичу.
Документация по получению данных из репозитория с помощью команды Blame и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Пользователи с ролями Designers и Developers легко могут объединяться для работы над дизайнами внутри тикета GitLab при помощи загрузки дизайнов через страницу управления дизайнами. Теперь дизайны можно загружать в новую область внутри тикета для легкого отслеживания и совместной работы.
Документация по странице управления дизайнами и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
В GitLab 12.2 мы также представляем управление версиями для страницы дизайнов, что позволит легко просматривать изменения в дизайне на протяжении времени, что упрощает отслеживание прогресса.
Документация по управлению дизайнами и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Очень важно сохранять порядок в реестре контейнера. Со временем образы в нем могут накапливаться и занимать значительную часть дискового пространства. Кроме того, большое число тегов может значительно увеличить время загрузки страницы управления реeстром контейнера, которая находится в Packages > Container Registry, что затрудняет работу с ней.
Ранее было несколько вариантов действий для поддержания порядка в вашем реестре, каждый со своими трудностями. Вы могли использовать API для массового удаления тегов для автоматизации процесса уборки, однако это требует написания и поддерживания скрипта. Также вы могли вручную удалять образы и теги со страницы управления реестром, но это занимало очень много времени, так как теги образов приходилось удалять по одному.
Теперь мы обновили и улучшили пользовательский интерфейс GitLab, чтобы сделать ручную уборку гораздо быстрее — вы можете выделять несколько тегов за раз, а при выделении образа вы автоматически выделите все связанные с ним теги. Это должно упростить сохранение порядка в вашем реестре, что позволит снизить расходы на хранилище и сохранить высокую скорость загрузки страницы. Мы с радостью делимся с вами этой версией реестра контейнера и уже готовим для вас новые улучшения. Следите за будущими обновлениями, вскоре появится возможность задавать политику сохранения и истечения срока действия.
Документация по реестру контейнера и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Бывает сложно упорядочивать большие списки тикетов, установить приоритет и/или порядок работы над ними, а это часто необходимо для типичных сценариев использования, таких как уход за бэклогом. Начиная с версии 12.2 вы сможете сортировать список тикетов в Manual (ручном) режиме, что позволит вам вручную перетаскивать тикеты в списке, чтобы расположить их в относительном порядке.
Этот порядок сохраняется в пределах всего инстанса для всех списков тикетов проекта и списков тикетов группы, в которых включен режим Manual.
Документация по ручной сортировке списков тикетов и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Использование одного и того же кластера Kubernetes для нескольких окружений может повысить эффективность. Например, если окружения dev и stage используют один и тот же кластер, то расходы на администрирование снижаются, потому что вам нужно управлять только одним кластером, а расходы на инфраструктуру снижаются, так как Kubernetes может разместить поды из обоих окружений на меньшее количество нод.
Ранее GitLab не слишком хорошо поддерживал этот вариант использования, и все окружения в проекте были развернуты в одном пространстве имен. Если вам нужны были отдельные разрешения для каждого окружения (например, если вы хотите разрешить развертывание на dev, но не на stage), приходилось использовать отдельный кластер для каждого. Интеграция GitLab с Kubernetes теперь использует отдельное пространство имен для каждого окружения в проекте, так что вы можете точно настроить разрешения отдельно для каждого и получить возросшую эффективность за счет использования одного и того же кластера для нескольких окружений.
Это позволит пользователям Kubernetes переиспользовать один и тот же кластер для разных окружений без необходимости развертывать все окружения в одном и том же пространстве имен. Кроме того, теперь операторы могут точно настраивать разрешения для каждого окружения, чтобы пользователи могли ограничить развертывание определенными окружениями.
Документация по настройке кластеров и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Если вы установили менеджер сертификатов в свой кластер Kubernetes через интеграцию GitLab с Kubernetes, теперь вы также можете удалить его одним кликом на странице кластера.
Документация по удалению приложений и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Если вы установили Helm в свой кластер Kubernetes через интеграцию GitLab с Kubernetes, теперь вы также можете легко его удалить на странице кластера.
Документация по удалению приложений и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Если вы установили Knative в свой кластер Kubernetes с помощью интеграции GitLab с Kubernetes, теперь вы также можете удалить его одним щелчком мыши со страницы кластера.
Документация по удалению приложений и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Владельцы теперь могут отключить уведомления по электронной почте на уровне группы или проекта, независимо от индивидуальных настроек пользователя. Если эта функция включена на уровне группы, она будет наследоваться всеми подгруппами и проектами внутри родительской группы.
Документация по отключению уведомлений по электронной почте и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Импорт существующих проектов из Bitbucket Server в GitLab должен быть простым процессом. Однако если у вас есть тысячи проектов, может быть сложно выбрать, какие репозитории Bitbucket импортировать.
В 12.2 мы предпринимаем шаги для упрощения таких миграций, добавляя фильтр по имени на странице импорта из Bitbucket Server, позволяющий вам указать, какие репозитории вы хотите импортировать. Мы рады добавить этот фильтр для всех, кто будет импортировать проекты в следующих релизах.
Документация по импорту из Bitbucket Server и оригинальный тикет
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Запуск нескольких инстансов процесса gitlab-runner на одном хосте может вызвать некоторые чрезвычайно запутанные и трудные для отладки ситуации. Поскольку это не предполагаемое использование, мы ввели файл блокировки, чтобы это не происходило случайно.
Документация по GitLab Runner и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
У нас уже есть ключевое слово parallel
, которое дает контроль и гибкость для настройки параллельных тестов (или действительно запускает любое задание в параллельном режиме), но это требует от разработчика большой работы по настройке, и иногда логика разделения просто дублируется. Существуют решения с открытым исходным кодом, такие как Test Boosters, которые продвинулись на шаг дальше, разделяя на несколько файлов еще и конфигурацию теста, чтобы вам не пришлось это делать самостоятельно. Мы обновили нашу документацию по ключевому слову parallel
, чтобы сделать процесс более очевидным и помочь большему количеству групп получить максимальную отдачу от своих конвейеров.
Документация по ключевому слову parallel в настройках CI и оригинальный тикет.
@
и :
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Мы добавили поддержку двух дополнительных символов, допустимых в значениях скрытых переменных, улучшив способность GitLab автоматически защищать больше разных секретов.
Документация по скрытым переменным и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
Для инстансов Prometheus с внешним управлением мы упростили сортировку и назначение инцидентов. Мы добавили поле gitlab_incident_markdown
, которое GitLab ищет в оповещениях и отображает в верхней части инцидентов в разделе Summary. GFM-разметку (GitLab Flavored Markdown) можно добавлять в файлы конфигурации оповещений в AlertManager и использовать для автоматического назначения и маркировки тикетов, открываемых из оповещений.
Документация по инстансам Prometheus с внешним управлением и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
Если вы настроили свой проект так, что тикеты из оповещений Prometheus создаются автоматически, метка incident
теперь также будет добавлена автоматически. Это позволяет группам реагирования на инциденты легко сортировать их с помощью досок задач и устраняет ручную работу по расстановке меток, отличающих тикеты для инцидентов от других.
Документация по действиям при инцидентах Prometheus и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Диаграммы метрик помогают визуализировать, какие изменения вызвали инцидент. Отображение диаграмм метрик непосредственно в тикетах позволяет приступить к работе сразу при возникновении тикета, посвященного инциденту, вместо того чтобы искать метрики в панелях по времени оповещения. Работая с инцидентом, дежурный инженер может использовать встроенные диаграммы для обмена знаниями и контекстом, которые он получил, изучая метрики и журналы. После того, как инцидент исчерпан, команда, выполняющая ретроспективный анализ, найдет все диаграммы в одном месте, включая метрики из начального оповещения и результаты расследований, выполненных во время «тушения пожара».
Чтобы встроить диаграммы метрик в тикеты, просто сгенерируйте общую ссылку на диаграмму в панели метрик. Вы можете указать временные рамки для данных, используя фильтр по времени на панели инструментов, и он будет сохранен в URL. Вставка этого URL в описание встраивает эти диаграммы в тикет.
При создании тикета для инцидента из оповещения можно использовать предварительно настроенный шаблон. Добавление диаграммы метрики в шаблон тикета автоматически встроит соответствующую диаграмму, показывающую значения метрик, относящиеся ко времени возникновения оповещения.
Документация по встраиванию метрик в тикеты для инцидентов Prometheus и оригинальный тикет.
(STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”
Создание заметок администратора для пользователей может быть полезным инструментом для администрирования большой пользовательской базы GitLab. На GitLab.com наши администраторы обычно используют атрибут note
для отслеживания поведения пользователя. Но через пользовательский интерфейс неудобно писать много заметок. Теперь вместо этого можно использовать пользовательский API для просмотра и создания заметок администратора, что беспрецедентно облегчает администраторам добавление напоминаний про пользователей.
Документация по API пользователей для администраторов и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Многие люди используют программы чтения с экрана для взаимодействия с GitLab. Чтобы такие программы могли озвучивать контент, им нужно, чтобы визуальная информация, такая как диаграммы, была также представлена в текстовом виде. GitLab теперь может выдать данные, представленные на диаграмме, в виде файла CSV, который можно загрузить и передать в приложение для чтения с экрана. Это можно сделать, открыв выпадающее меню в верхнем правом углу нужной диаграммы и выбрав опцию загрузки CSV.
Документация по мониторингу окружений CI/CD для Prometheus и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Теперь вы можете установить панель безопасности группы в качестве экрана по умолчанию при просмотре группы. Примечательно, что это делается отдельно для каждого пользователя, а это означает, что каждый в команде может выбрать вид по своему вкусу.
Это позволяет группам безопасности и пользователям, наиболее заинтересованным в безопасности группы, быстро определять состояние безопасности без необходимости перемещаться по меню для поиска информации.
Документация по настройке просмотра групп и оригинальный тикет.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.2 released with Directed Acyclic Graphs for Pipelines and Design Management.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.