Вышел релиз GitLab 13.0 с кластерами Gitaly, иерархией эпиков на дорожных картах и автоматическим развертыванием для ECS
Что изменилось со времени 12.0
Прежде чем приступить к описанию нового мажорного релиза 13.0, мы хотели бы уделить внимание пройденному пути. Мы столького достигли с момента выхода версии 12.0! Недавно в блоге вышел специальный пост, в котором мы сделали обзор релизов GitLab с 12.0 по 12.10. Три наших фаворита из этой серии релизов это управление требованиями, сетевая безопасность контейнеров и конвейеры (в русской локализации GitLab «сборочные линии») родитель-ребенок.
В дополнение к улучшениям самого продукта мы также обновили наши партнерские программы и интеграции, добавили рекомендации по интеграции для использования сторонних сканеров безопасности, а также расширили наши пакеты услуг техподдержки, чтобы помочь вам с такими вещами, как миграции Jira и Jenkins. На нашем новом видеоканале Learn@GitLab вы найдете множество видеоуроков. Например, Начало работы с CI.
Итерации — ключ к устойчивости
GitLab помогает ИТ- и бизнес-командам развиваться, вовремя реагировать и адаптироваться, и ключ ко всему этому — итерации. Пользователям необходимо быстро взаимодействовать, оптимизировать работу и автоматизировать процессы для обеспечения безопасности и соответствия требованиям, не забывая при этом о качестве продукта. GitLab 13.0 поможет вам итерировать быстро и с более глубоким пониманием процесса. Доступ к Git-репозиториям также является критически важным, и мы усовершенствовали наш кластер Gitaly для высокодоступных (HA) хранилищ Git, чтобы в случае сбоя всегда имелось несколько свежих и готовых к работе реплик.
Оперативное реагирование и сотрудничество всей команды
GitLab расширяет возможности, которые способствуют совместной разработке, созданию отчетов, организации и управлению работой. В основе совместной работы лежит контроль версий, и в релизе 13.0 мы добавляем контроль версий сниппетов. Для управления более сложными проектами в 13.0 появилась возможность просматривать иерархию эпиков (в русской локализации GitLab «цели») на вашей дорожной карте (в русской локализации GitLab «план развития»), как соотносятся ваши эпики и майлстоуны (в русской локализации GitLab «этапы») и добавлять один или несколько майлстоунов к своим релизам. Оповещения о закрытии тикета с открытыми блокирующими тикетами помогут вам обратить внимание на ключевые моменты пути.
Дизайнеры — важная часть команды разработчиков. Работая над одной из самых популярных новых фич, темной темой для Web IDE, мы поняли, как привлечь дизайнеров к более тесному сотрудничеству. Также мы переместили управление дизайном в план Core, тем самым отмечая пользователей, которые занимаются дизайном продуктов, как отдельных участников.
Оптимизация для повышения эффективности
Поскольку многие компании стремятся быть более оперативными и более эффективными, GitLab старается упростить существующие процессы разработки программного обеспечения. Новые фичи, направленные на повышение эффективности, включают в себя упрощенное развертывание на Amazon ECS и новый объединенный список оповещений, который объединяет IT-оповещения, поступающие из нескольких источников, в едином интерфейсе. Кроме того, у нас есть хорошая новость и для пользователей Terraform. В GitLab 13.0 появился краткий обзор результата terraform plan в мерж-реквестах (в русской локализации GitLab «запросы на слияние») и использование GitLab в качестве бэкенда для state файла.
Доверяйте вашим процессам и не жертвуйте безопасностью и соответствием требованиям
GitLab помогает компаниям комплексно внедрять средства контроля безопасности и соответствия требованиям в жизненный цикл разработки ПО, снижая риски и высвобождая ресурсы для критически важных потребностей бизнеса. Наши возможности тестирования безопасности приложений помогают вам быстрее находить и исправлять уязвимости безопасности, благодаря чему GitLab недавно был назван нишевым игроком в Gartner Magic Quadrant for Application Security Testing 2020 года.
С момента оценки Gartner релиза 12.4 мы добавили много новых фич. А в 13.0 мы добавили возможность сканирования REST API через DAST и полное сканирование истории коммитов на наличие секретных ключей. Более того, мы поменяли наш способ работы с объектами уязвимостей. Благодаря этому появилась возможность экспортировать уязвимости из панели безопасности и в будущем будут доступны более широкие возможности управления уязвимостями.
В дополнение к сканированию безопасности в релизе 13.0 GitLab автоматизирует правила и обеспечивает более детальный контроль с помощью заморозки развертывания с помощью API Freeze Periods. Это поможет легко предотвратить непреднамеренные релизы в продакшн на указанный промежуток времени. Для упрощения аудитов в 13.0 появилась фильтрация в поиске событий аудита на уровне инстанса, это часть нашего эпика по событиям аудита.
А что впереди?
Мы с энтузиазмом готовим предстоящие релизы, в частности, фичи, которые помогут вам:
-
Обеспечить соответствие требованиям и автоматически применять соответствующие меры контроля и отчетности.
-
Получать больше инсайтов благодаря выпуску версий с A/B-тестированием и контролировать их с помощью нескольких улучшений для переключаемых фич — фильтрация фич по статусу, A/B-тестирование на основе переключаемых фич и возможность создавать переключаемые фичи из мерж-реквеста).
-
Определять узкие места и потери благодаря отображению стадий в аналитике цикла разработки в виде потока.
-
Управлять правилами и оставлять GitLab автоматизацию их использования, включая готовый набор сетевых правил безопасности контейнера.
-
Тестировать API приложений фаззингом, а также считывать переменные CI из хранилища HashiCorp.
Хотите увидеть полный список того, что выйдет в следующем месяце? Наша дорожная карта открыта и всегда доступна для всех желающих внести свой вклад.
Теперь, без лишних слов, приступим к описанию всех классных фич релиза 13.0!
MVP этого месяца — Sashi
Sashi добавил огромное количество улучшений в релиз 13.0 в различных разделах GitLab. Его работа помогла улучшить контроль версий сниппетов, удалить ошибки, связанные с тегом Releases, и минимизировать дублирование событий, посылаемых веб-хуками. Также он улучшил структуру и читаемость кода, обеспечив каждому формату пакета уникальную модель для хранения метаданных.
Спасибо Sashi за всю эту работу!
Ключевые фичи релиза GitLab 13.0
Кластер Gitaly для высокодоступных хранилищ Git
(PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
GitLab теперь поддерживает высокодоступные системы хранения Git без использования NFS. Конфигурации высокой доступности (high availability, HA) повышают доступность важных систем, таких как хранилища Git, за счет устранения единичных точек отказа, обнаружения сбоев и автоматического переключения на реплику. Это означает, что отдельный компонент системы может выйти из строя, не вызвав сбоя у конечного пользователя. Доступ к репозиториям Git очень важен для разработчиков и компаний, поскольку при его выходе из строя разработчики не смогут отправлять код и развертывание будет заблокировано.
Внутри Git-репозитория хранилище обрабатывается Gitaly, а теперь еще и Praefect. Praefect — это новый маршрутизатор и менеджер транзакций, который мы создали специально для Gitaly, чтобы координировать выбор лидера и асинхронную репликацию. При использовании кластера Gitaly запросы на данные Git направляются через одну из нескольких нод Praefect на ноду Gitaly. Таким образом всегда есть несколько реплик, готовых принять управление на себя в случае сбоя в работе.
В будущем мы планируем добавить поддержку сильной согласованности, чтобы операции записи успешно выполнились на нескольких нодах Gitaly, прежде чем отправится ответ об успешности записи, и поддержку горизонтального распределения чтения, чтобы ресурсы процессора и памяти могли быть лучше масштабированы.
Документация по Praefect и оригинальный эпик.
Автоматическое развертывание в ECS
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
До сих пор у нас не было простого способа развертывания в Amazon Web Services. Из-за этого пользователям GitLab приходилось тратить много времени на настройку собственной конфигурации.
В GitLab 13.0 поддержка развертывания в AWS уже ждет вас в Auto DevOps! Пользователи GitLab, которые развертывают в Elastic Container Service (ECS) от AWS, теперь могут воспользоваться возможностями Auto DevOps, даже если они не используют Kubernetes. Auto DevOps упрощает и ускоряет поставку и облачное развертывание с помощью полного конвейера поставки сразу из коробки. Благодаря устранению лишних сложностей вы сможете сконцентрироваться на аспектах создания программного обеспечения. Просто отправьте коммит, а GitLab сделает все остальное!
Чтобы подключить эту фичу, необходимо определить переменные окружения для AWS: ‘AWS_ACCESS_KEY_ID’, ‘AWS_ACCOUNT_ID’ и ‘AWS_REGION’, а также включить Auto DevOps. Затем ваше развертывание ECS будет автоматически собрано для вас с полным автоматическим конвейером поставки.
Документация по развертыванию в ECS и оригинальный тикет.
Просмотр иерархии эпиков на дорожной карте
(ULTIMATE, GOLD) Стадия цикла DevOps: Plan
При работе с многоуровневыми эпиками бывает сложно отследить, где находится каждый дочерний эпик на дорожной карте. Теперь вы сможете развернуть родительский эпик на вашей дорожной карте, чтобы просмотреть все его вложенные эпики и обеспечить правильную организацию работы и соблюдение запланированного графика.
Документация по дорожным картам и оригинальный тикет.
Контроль версий для сниппетов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Сниппеты полезны для обмена небольшими фрагментами кода и текста, которые могут не входить в основную кодовую базу проекта. Эти фрагменты важны для групп и пользователей, которые используют их для таких задач, как скрипты, генерирующие результаты диагностики, или настройка поддерживающих сервисов для тестовых и демонстрационных окружений. К сожалению, из-за отсутствия контроля версий было трудно выяснить, был ли этот сниппет последней версии, какие изменения могли произойти и как их свести воедино.
Теперь сниппеты в GitLab также находятся под контролем версий в Git-репозитории. При редактировании сниппета каждое изменение создает коммит. Сниппеты также можно клонировать для локального редактирования, а затем отправлять в репозиторий Snippet.
Это — первый шаг на пути к удобной совместной работе над сниппетами. В будущих релизах мы введем поддержку для нескольких файлов, продолжим расширять возможности и разрешения для сниппетов.
Документация по контролю версий в сниппетах и оригинальный тикет.
Темная тема в Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Для людей, которые проводят много времени за работой в редакторах кода, очень важна возможность настраивать среду разработки в соответствии с их предпочтениями. Темные темы являются одними из наиболее популярных для редакторов и играют важную роль в обеспечении комфортной работы. Также очевидно, что пользователи GitLab любят темные темы, поскольку тема Dark Application для всего интерфейса GitLab является вторым по популярности запросом в нашем трекере задач.
Web IDE теперь полностью темная для всех пользователей, выбравших Dark в настройках темы подсветки синтаксиса. Это важный шаг в обеспечении удобства редактирования и в понимании того, как пользовательский интерфейс GitLab взаимодействует с темными темами. Вы можете узнать больше о разработке этого дизайна в соответствующем посте.
Документация о темах в Web IDE и оригинальный тикет.
Отдельные объекты уязвимостей
(ULTIMATE, GOLD) Стадия цикла DevOps: Defend
Мы представляем первую фичу для управления уязвимостями: отдельные объекты уязвимостей. В 13.0 мы создали новую модель объектов уязвимостей, что позволило нам получить совершенно новый набор возможностей, охватывающих весь жизненный цикл управления уязвимостями.
Одно из самых больших преимуществ заключается в том, что теперь каждая уязвимость будет иметь уникальный URL. Это означает, что на уязвимость можно ссылаться напрямую, делиться ей и отслеживать ее как единый источник информации. На этой странице вы можете изменить статус уязвимости на «Обнаружена» (“Detected”), «Подтверждена» (“Confirmed”), «Проигнорирована» (“Dismissed”) или «Решена» (“Resolved”). Еще одним преимуществом является то, что обнаруженные уязвимости будут сохраняться при следующем запуске сканера. Ранее запуск сканирования на той же ветке перезаписывал все предыдущие результаты новыми. Сохранение прошлых объектов уязвимостей улучшит качество отслеживания, наглядность и сократит дублирование результатов между прогонами сканера. Кроме того, это даст в будущем возможность создавать отчеты о тенденциях уязвимостей в группах и проектах с течением времени по широкому ряду параметров.
Документация по уязвимостям и оригинальный тикет.
Поддержка REST API в сканированиях DAST
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
В GitLab 13.0 мы добавили DAST сканирования REST API. Это позволит обеспечить полное DAST-покрытие безопасности всего приложения, а не только пользовательского интерфейса. DAST поддерживает использование спецификации OpenAPI в качестве руководства по сканированию URL-адресов и конечных точек REST, что позволит обеспечить безопасность всех направлений атак и даст больше информации о потенциальных уязвимостях любого работающего приложения.
Документация по DAST-сканированию API и оригинальный тикет.
SAST для .NET Framework
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Мы представляем начальную поддержку .Net Framework, которая позволит разработчикам запускать сканирования безопасности SAST в дополнительных типах .NET проектов. Как и в других наших заданиях SAST, в них будут использоваться обработчики заданий GitLab (runner) для Linux. В будущем мы планируем добавить поддержку обработчиков заданий Windows. С момента появления в GitLab 11.0, SAST для .NET включал в себя поддержку только для проектов .NET Core.
| Поддерживаемый язык | Инструмент сканирования | Представлен в версии GitLab |
|---|---|---|
| .NET Core | Сканирование безопасности кода | 11.0 |
| .Net Framework | Сканирование безопасности кода | 13.0 |
Документация по поддерживаемым SAST языкам и оригинальный тикет.
Краткий обзор результата terraform plan в мерж-реквестах
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure
Если вы используете Terraform для определения вашей инфраструктуры в виде кода, вы знаете, как удручает необходимость постоянно передавать коллегам итоговые изменения из команды terraform plan в slack и комментариях в мерж-реквестах. В GitLab 13.0 теперь вы будете видеть краткий обзор вывода команды terraform plan в том контексте, где это наиболее полезно — непосредственно в вашем мерж-реквесте. Это поможет вам быстрее проверять изменения в вашей инфраструктуре и предоставит удобное место для взаимодействия с членами вашей команды по предполагаемому влиянию на вашу инфраструктуру по мере изменения кода.
Пользователи шаблона Terraform, предлагаемого GitLab, увидят виджет мерж-реквеста terraform plan без какой-либо дополнительной настройки. Пользователи персонализированных шаблонов CI/CD могут обновить свой шаблон, чтобы использовать образ и скрипты официального шаблона Terraform от GitLab.
Документация по работе с инфраструктурой с помощью Terraform и оригинальный эпик.
Использование GitLab в качестве бэкенда для state файла Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure
Пользователи Terraform прекрасно знакомы с трудностями настройки state файла (карта связей вашей конфигурации с реальными ресурсами, в которой также отслеживаются дополнительные метаданные). Этот процесс включает в себя создание нового проекта Terraform и настройку стороннего бэкенда для хранения надежного, безопасного и не зависящего от вашего git-репозитория файла состояния.
Многие пользователи искали более простой способ настройки файлового хранилища без использования дополнительных сервисов или настроек. Начиная с GitLab 13.0 как HTTP-бэкенд для Terraform можно использовать сам GitLab, что устраняет необходимость настраивать отдельное хранилище для state файлов для каждого нового проекта.
Бэкенд состояний Terraform от GitLab обеспечивает простоту настройки и возможность хранить ваши state файлы в месте, контролируемом инстансом GitLab. Доступ к ним можно получить с помощью специального HTTP-бэкенда, используя GitLab для аутентификации. Пользователи смогут легко мигрировать на HTTP-бэкенд Terraform от GitLab, а также получить к нему доступ со своих локальных терминалов.
HTTP-бэкенд для состояний Terraform от GitLab поддерживает:
- Многочисленные именованные файлы состояния в одном проекте
- Блокировку
- Хранилище объектов
- Шифрование в состоянии покоя
Все это теперь доступно и для пользовательских инстансов GitLab, и на GitLab.com.
Документация по работе с инфраструктурой с помощью Terraform и оригинальный эпик.
Исключайте большие файлы с помощью частичного клонирования
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Хранение больших бинарных файлов в Git обычно не приветствуется, поскольку все добавленные файлы будут загружены каждым, кто впоследствии клонирует или проверяет обновления (git fetch) репозитория. Это сильно замедляет, если вовсе не останавливает, работу при медленном или ненадежном соединении.
В GitLab 13.0 частичное клонирование было включено для фильтров по размеру блоба, а также экспериментально для других фильтров. Это позволяет исключить проблемные большие файлы из клонирований и скачиваний обновлений. Когда Git обнаруживает недостающий файл, он будет загружен по требованию. При клонировании проекта используйте --filter=blob:none для полного исключения блобов или --filer=blob:limit=1m для исключения по размеру файла. Обратите внимание, что для частичного клонирования требуется версия Git не ниже 2.22.0.
Узнайте все подробности в нашем недавнем посте Как частичное клонирование в Git позволяет вам получать только необходимые большие файлы.
Документация по частичному клонированию и оригинальный тикет.
Управление панелями метрик через переменные
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
В GitLab 13.0 вы можете создавать панели метрик, управляемые через переменные. Это позволит вам использовать одну панель метрик для мониторинга нескольких различных сервисов и компонентов, вместо того, чтобы каждый раз создавать панели метрик со вшитыми параметрами для каждого сервиса, который вы хотите мониторить. Вместо того, чтобы много раз подолгу создавать похожие панели метрик, теперь вы можете создать одну панель метрик и использовать переменные, чтобы настраивать, какие данные будут на ней выводиться.
Документация по шаблонам переменных для панелей метрик и оригинальный эпик.
Сниженное потребление памяти GitLab с Puma
(CORE, STARTER, PREMIUM, ULTIMATE) Доступность
Puma теперь по умолчанию является сервером веб-приложений для установок на основе Omnibus и Helm. Puma снижает объем памяти, потребляемой GitLab, примерно на 40% по сравнению с Unicorn, что повышает эффективность работы GitLab и позволяет потенциально сэкономить на стоимости инстансов с самостоятельным управлением.
Установкам, которые настроили количество процессов Unicorn, или используют более медленные диски с NFS, возможно придется изменить конфигурацию Puma по умолчанию. Посмотрите важные заметки по обновлениям и улучшения в GitLab chart, чтобы узнать больше.
Документация по Puma и оригинальный эпик.
Другие улучшения в GitLab 13.0
Фильтр для поиска по событиям аудита в инстансе
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
Если вам нужно найти определенное событие для отчета по аудиту или для расследования инцидента, это должно быть просто. Вы не должны тратить кучу времени на то, чтобы вручную копаться в большом наборе данных.
Теперь вы можете искать одиночный объект (например, пользователя, группу или проект) с помощью фильтров в таблице событий аудита инстанса, что значительно упрощает этот процесс. Эта фича доступна только для пользователей в инстансах с самостоятельным управлением, однако она будет расширена до групп и проектов как часть большого эпика по событиям аудита. Это позволит привести события аудита инстанса, группы и проекта к единому стандарту и сделает их более удобными для использования.
Документация по событиям аудита и оригинальный тикет.
Включение защиты веток по умолчанию на уровне группы
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
Раньше при переносе настроек защиты ветки по умолчанию с уровня инстанса на уровень проектов можно было легко запутаться, потому что в некоторых сценариях этот процесс был неинтуитивным: разработчики не могли добавлять новые коммиты в проекты, которые они же и создали. Из-за этого организациям было сложно найти баланс между снижением рисков и предоставлением свободного доступа к проектам для всех разработчиков, так как решение проблемы требовало повышения их до maintainer (в русской локализации GitLab «сопровождающий»).
Теперь защиту веток по умолчанию можно настроить на уровне группы, чтобы предоставить большую гибкость для администраторов и владельцев групп. Используя комбинацию защиты веток по умолчанию и настроек создания проекта по умолчанию, организации смогут найти нужный баланс между автономией и контролем. Например, использовать свои настройки для защиты веток по умолчанию и разрешать создавать новые проекты только пользователям с ролями maintainer. Это позволит разработчикам добавлять новые коммиты (без принудительного пуша или удаления веток) к новым проектам, при этом оставляя создание проектов maintainers.
Настройку владельцем группы защиты веток по умолчанию может отключить администратор, если в вашей организации требуется больше контроля. После ее отключения maintainers смогут более строго управлять доступом и разрешениями для разработчиков.
Документация по настройке защиты веток по умолчанию на уровне группы и оригинальный тикет.
Аналитика цикла разработки: график задач по типу
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage
Новый мощный график позволит командам наблюдать, как время поставки распределяется по разным типам работ. Используйте метки, чтобы посмотреть, сколько времени тратится на фичи по сравнению с багами из релиза в релиз, или сколько элементов поставляет одна команда по сравнению с другой. Анализируя циклы работы, команды смогут регулировать свои процессы, чтобы они лучше согласовывались со стратегическими целями или для более сбалансированного распределения ресурсов между командами.
|  |
Документация по графику задач по типу работы и оригинальный тикет.
Email-уведомления при авторизации из неизвестного источника
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
Пользователи теперь будут получать email-уведомление, когда их данные для входа используются с нового устройства или IP-адреса. Это позволит пользователям быстро обнаруживать потенциальную активность злоумышленников, связанную с их учетными записями.
Документация по уведомлениям при авторизации из неизвестных источников и оригинальный тикет.
Предупреждение при закрытии тикета с неразрешенными зависимостями
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan
В GitLab 12.8 мы добавили возможность создавать зависимости между тикетами, так что один тикет может блокировать другой. Это означает, что зависимый тикет не может быть закрыт, пока не будет завершен и закрыт главный. Из-за этого вам приходилось перед закрытием тикета проверять, не является ли он заблокированным другими.
Проверка тикета на блокировщики перед его закрытием – это лишний шаг, про который легко забыть. Мы избавили вас от необходимости делать этот шаг, добавив предупреждение, которое будет появляться при попытке закрыть тикет с неразрешенными зависимостями, а также ссылки на неразрешенные блокирующие тикеты, чтобы вы могли проверить, безопасно ли закрывать этот тикет.
Эти уведомления о зависимостях позволят вашим проектам работать без заминок, а также обеспечат правильную последовательность тикетов.
Документация по зависимостям между тикетам и оригинальный тикет.
Более удобное добавление эпиков и тикетов через дерево эпиков
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Plan
Создание и добавление тикетов и эпиков через дерево эпиков ранее было разделено по нескольким кнопкам и выпадающим меню, и поэтому его было неудобно использовать. Мы объединили действия “add” (добавить) и “create” (создать) в отдельную кнопку с меню, чтобы добавлять новые тикеты и эпики было проще и быстрее!
Документация по добавлению тикетов в эпик и оригинальный тикет.
Эмодзи в обсуждении дизайнов 👍
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
В версии 13.0 обсуждения дизайнов стали на шаг ближе к комментариям в GitLab. Мы добавили поддержку эмодзи, чтобы вы могли давать обратную связь более веселым и креативным способом! 😼
Документация по обсуждениям дизайнов и оригинальный тикет.
Новый режим сравнения для мерж-реквестов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Мерж-реквесты, особенно вкладка Изменения (Changes), — это место, где происходит обсуждение и ревью исходного кода. В случаях, когда целевая ветка была смержена в исходную ветку мерж-реквеста, изменения в исходной и целевой ветках могут оказаться перемешанными, из-за чего становится сложно понять, какие изменения добавляются, а какие уже существуют в целевой ветке.
В GitLab 13.0 мы добавляем экспериментальный режим сравнения. Он будет показывать дифф, рассчитанный путем симуляции мержа, что даст более точное представление изменений, чем использование мержей обеих веток. Этот режим доступен в выпадающем меню ветки, выбранной для сравнения через пункт master (HEAD). В будущем этот режим заменит текущий способ сравнения по умолчанию.
Документация по режиму сравнения для мерж-реквестов и оригинальный тикет.
Темы подсветки синтаксиса для Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
GitLab поддерживает шесть тем подсветки синтаксиса при просмотре кода. Темы крайне важны для удобства разработчиков при просмотре и редактировании кода в GitLab. Теперь мы добавили поддержку всех шести тем подсветки синтаксиса в Web IDE, включая Solarized Dark, Solarized Light, Monokai и режим «без подсветки».
На протяжении нескольких последних релизов (например, в 12.8 и 12.9) мы добавляли и улучшали поддержку тем подсветки в Web IDE. Новые темы подсветки являются продолжением этой работы и помогли заложить основу для нашей темной темы в Web IDE, которая также выходит в 13.0. Мы продолжаем улучшать интерфейс для разработчиков и делать нашу Web IDE более комфортной.
Документация по темам Web IDE и оригинальный эпик.
Подсветка пинов комментариев к дизайну для удобного обсуждения
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Когда над одним дизайном ведется много обсуждений, становится сложно определить, какие обсуждения относятся к какому пину, без поиска номера этого комментария.
В релизе 13.0 мы добавили механизм подсветки пинов релевантных комментариев при клике на исходный комментарий. Мы также добавили обратную фичу, чтобы вы могли кликнуть на пин и перейти к исходному комментарию. Это позволит не тратить время на то, чтобы вручную листать комментарии в поисках нужного, когда под дизайном много комментариев.
Документация по обсуждениям дизайнов и оригинальный тикет.
Правила пушей для групп
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
Правила пушей обеспечивают дополнительный контроль за тем, что можно и нельзя отправлять в ваш репозиторий. Они позволяют вам создавать свои стандарты, которые соответствуют правилам вашей организации.
Ранее правила пушей можно было задавать только на уровне инстанса или проекта, из-за чего админам приходилось управлять большим числом людей и проектов независимо. Настройка правил пушей на уровне групп позволит владельцам групп централизованно управлять безопасностью, и в то же время оставлять независимость отдельным владельцам проектов.
Документация по правилам пушей для групп и оригинальный тикет.
Кнопки навигации по коммитам в мерж-реквестах
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Удобная навигация по коммитам в больших мерж-реквестах позволяет более эффективно проводить ревью с перемещением между коммитами.
Новые кнопки навигации по коммиту позволяют пользователям удобно перемещаться от текущего коммита к следующему или предыдущему, делая более эффективным процесс ревью мерж-реквестов с большим числом изменений.
Документация о навигации по коммитам мерж-реквеста и оригинальный тикет.
Доступ к отчетам JUnit через API GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Отчет JUnit может содержать информацию для обновления планов тестирования, истории выполнения тестов и других артефактов, которые команды используют, чтобы следить за качеством своего кода. Обновление этих артефактов может быть долгим и утомительным процессом. Что еще хуже, отчеты были JUnit доступны только путем скачивания через пользовательский интерфейс GitLab. Начиная с версии GitLab 13.0 пользователи API GitLab смогут получать доступ к отчетам JUnit напрямую. Это позволит пользователям парсить данные JUnit для создания новых тикетов или обновления истории выполнения тестов.
Документация по отчетам о выполнении тестов на конвейере и оригинальный тикет.
Фильтр для конвейеров по автору триггера и названию ветки
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Поиск конвейеров, запущенных определенным пользователем или на определенной ветке, стал проще, чем когда-либо. С новым фильтром на странице конвейеров вы сможете фильтровать коммиты по автору коммита и/или по названию ветки. Настройка страницы конвейеров при помощи этих фильтров позволит вам получать актуальную информацию об активности тех конвейеров, которые наиболее важны для вас.
Документация по странице конвейеров и оригинальный тикет.
Доступ к реестру пакетов GitLab для чтения или записи через токены развертывания
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package
Токены развертывания позволяют вам получать доступ к репозиториям группы, репозиториям проекта и реестрам контейнеров. Команды read_repository, read_registry и write_registry ранее не позволяли вам получать доступ к реестру пакетов GitLab. В результате командам DevOps приходилось использовать небезопасные или дорогостоящие обходные пути.
В GitLab 13.0 мы добавили более точные настройки разрешений токенов развертывания GitLab. Теперь вы можете задавать доступ к реестру пакетов для чтения или записи. Создавать токены развертывания и управлять ими можно из приложения GitLab или через API.
Документация по токенам развертывания и оригинальный тикет.
Все версии пакета под одним именем
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package
Реестр пакетов GitLab ранее рассматривал каждую новую версию пакета как новый пакет. Из-за этого было сложно искать нужные пакеты или сравнивать изменения между разными версиями пакета.
В GitLab 13.0 каждая версия пакета будет находиться под родительским пакетом с уникальным именем. Это упростит поиск нужного пакета через пользовательский интерфейс и просмотр изменений между версиями. Это обновление применяется для уровней групп и проектов в реестре пакетов. Кроме того, при использовании API пакетов версии пакета будут возвращаться как массив под именем родительского пакета.
Документация по получению пакета проекта и оригинальный тикет.
Заморозка развертывания через API Freeze Period
(ULTIMATE, GOLD) Стадия цикла DevOps: Release
С этим релизом GitLab предоставляет больше способов управлять окружениями. Новый API Freeze Period позволит вам легко предотвратить непреднамеренный релиз в продакшн в течение заданного вами периода, например, во время праздника или корпоративного события. Теперь вы можете пользоваться правилами, которые обычно находятся за пределами GitLab, чтобы уменьшить неопределенность и риск при автоматизации развертываний.
Документация по замораживанию развертываний и оригинальный тикет.
Обновление майлстоунов релиза через пользовательский интерфейс GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release
Команда управления разделом Релизов GitLab работает над расширением страницы релиза для использования всей функциональности API релизов. В версии 13.0 стало проще добавлять один или несколько майлстоунов к вашим релизам. С этим обновлением вам больше не придется вручную вызывать API релизов, чтобы пользоваться фичами для планирования, такими как просмотр прогресса по релизу, который был представлен в версии 12.9.
Документация по редактированию релиза и оригинальный тикет.
Поиск образов по имени в реестре контейнеров GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package
Когда вы или кто-то в вашей команде публикует образ в реестр контейнеров GitLab, вам нужен способ быстро найти этот образ и убедиться, что он был собран правильно. Раньше, если вы использовали GitLab CI/CD для публикации образов с каждой сборкой, через пользовательский интерфейс было сложно эффективно проводить поиск образов. Вместо этого вам приходилось полагаться на командную строку или API.
В версии 13.0 мы добавили поиск по реестру контейнеров GitLab. Просто перейдите к реестру вашего проекта или группы и введите имя образа, чтобы просмотреть список всех образов, которые у вас есть.
Документация по управлению реестром контейнеров через GitLab и оригинальный тикет.
Просмотр нагрузки и аннотаций внешних IT-уведомлений в GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
Список уведомлений полезен при сортировке проблем на высоком уровне, однако в нем недостаточно места для всех атрибутов уведомлений и для нагрузки. Новая страница с деталями по уведомлению предназначена для отображения и организации нагрузки и аннотаций, чтобы при расследовании проблемы было проще находить критически важную информацию.
Документация по странице уведомлений и оригинальный тикет.
Рендер эмодзи на странице состояния проекта
(ULTIMATE, GOLD) Стадия цикла DevOps: Monitor
Тикеты GitLab поддерживают эмодзи в имени тикета и во всех полях с поддержкой Markdown. Теперь при публикации тикета через публичный URL как страницы статуса проекта на этой странице поддерживаются и рендерятся эмодзи, использованные в имени, описаниях и комментариях к тикету.
Документация по странице информации по инциденту и оригинальный тикет.
Переключение видимости панели метрик
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
Ранее администраторы проекта не могли управлять разрешениями на просмотр панели метрик проекта. В GitLab 13.0 администраторы смогут разрешать видимость панели метрик либо только участникам проекта, либо всем пользователям с правами доступа.
Документация по видимости панели метрик и оригинальный тикет.
Добавление аннотаций на панель метрик
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
Иногда графики метрик становятся сложными для понимания. Начиная с GitLab 13.0 вы сможете добавлять аннотации к своим графикам метрик, в виде горизонтальных пунктирных линий поверх ваших графиков и диаграмм. Они помогут вам правильно интерпретировать данные.
Документация по аннотациям на панелях метрик Prometheus и оригинальный эпик.
Поиск секретных ключей в полной истории репозитория
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
В GitLab 13.0 мы обновляем наше сканирование для поиска секретных ключей для поддержки новой переменной SAST_GITLEAKS_HISTORIC_SCAN, что позволит проводить сканирование полной истории репозитория. Это поможет вам находить ключи, которые могли затеряться среди старых коммитов. На момент появления в GitLab 11.9 сканирование для поиска секретных ключей проводилось по истории изменений в коммитах мерж-реквеста, что позволяло находить новые добавленные ключи, но не затрагивало более давнюю историю коммитов. Наша новая фича будет особенно полезна при использовании поиска секретных ключей в репозитории в первый раз — для полного сканирования репозитория на наличие ключей.
Мы сняли короткую видеоинструкцию, чтобы показать, как вы можете проводить сканирование истории для поиска ключей через конвейер, работающий по графику или конвейер с ручным запуском.
Документация по сканированию истории репозитория для поиска секретных ключей и оригинальный эпик.
Экспорт списка уязвимостей из панелей безопасности инстанса и проекта
(ULTIMATE, GOLD) Стадия цикла DevOps: Defend
Мы представляем первую итерацию экспорта списка уязвимостей из панели безопасности инстанса и панели безопасности проекта. Хотя панели безопасности позволяют пользователям управлять уязвимостями в рамках их рабочего процесса в GitLab, раньше было непросто получить эту информацию в виде списка для внешнего использования.
Теперь вы можете загружать файл в формате CSV со всеми обнаруженными уязвимостями для определенного проекта или для всех проектов, управляемых на панели безопасности инстанса. Этот список можно использовать для создания отчетов по безопасности или как источник данных для внешних панелей безопасности. Просто перейдите к панели безопасности инстанса или к панели безопасности любого проекта и нажмите новую кнопку Export справа вверху или выберите Security в меню More на верхней панели навигации, затем нажмите новую кнопку Export в правом верхнем углу. Ваш браузер автоматически начнет загрузку.
Документация по экспорту уязвимостей и оригинальный тикет.
Интеграция SIEM с файерволом веб-приложений
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Defend
Мы объявляем о новой интеграции SIEM для файервола веб-приложений (WAF). Эта интеграция позволяет пользователям экспортировать свои логи WAF в SIEM или в централизованное решение для логирования, чтобы можно было просматривать любые аномалии, обнаруженные WAF. Эта фича также облегчает пользователям тестирование и настройку пользовательских правил WAF, что уменьшает количество ложных срабатываний. Интеграцию SIEM можно настроить, включив Fluentd на странице Операции > Kubernetes (Operations > Kubernetes).
Документация по Fluentd и оригинальный тикет.
Вторичные ноды Geo автоматически пересылают запросы SSH для несинхронизированных репозиториев
(PREMIUM, ULTIMATE) Доступность
Geo поддерживает выборочную синхронизацию проектов, что позволяет системным администраторам выбирать подмножество данных, реплицируемое во вторичные ноды Geo. Geo уже поддерживает перенаправление запросов HTTP(S) на основной сервер при попытке доступа к этим несинхронизированным репозиториям. Однако пользователи, пытавщиеся получить доступ к несинхронизированным репозиториям на вторичной ноде через SSH, получали сообщение об ошибке, что репозиторий недоступен. Это сбивало с толку пользователей и заставляло их либо ждать синхронизации хранилища, либо выполнять дополнительную работу для подключения к нужному хранилищу.
В GitLab 13.0 любые запросы Git, сделанные через SSH к несинхронизированной вторичной ноде Geo, будут перенаправлены на первичную ноду. Это приводит к гораздо более плавному взаимодействию с пользователями, поскольку им не нужно будет знать, что реплицируется или не реплицируется на эту ноду: Geo выполнит запрос как по HTTP(S), так и по SSH без какой-либо дополнительной настройки.
Документация по настройке операций Git с нереплицированными репозиториеями и оригинальный эпик.
Обработчик заданий теперь поддерживает загрузку артефактов непосредственно из хранилища объектов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Обработчик заданий GitLab (GitLab Runner) 13.0 теперь поддерживает загрузку артефактов непосредственно из хранилища объектов. Когда эта опция включена, сервер GitLab будет перенаправлять обработчик заданий непосредственно в хранилище объектов, а не проксировать трафик. Это может привести к значительной экономии затрат на передачу по сети, а также к снижению нагрузки на сервер GitLab.
Для подключения установите переключаемую фичу FF_USE_DIRECT_DOWNLOAD в true через переменную окружения.
Документация по доступным переключаемым фичам и оригинальный тикет.
Добавлены события аудита для действий администратора под именем пользователя
(PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Возможность проводить аудит и отслеживать изменения являются важными компонентами программы соответствия требованиям для организации. Ранее действия, предпринимаемые администратором от имени другого пользователя, регистрировались в таблице событий аудита, как если бы этот пользователь сам выполнял эти действия. Теперь события аудита покажут вам, когда определенные действия были выполнены администратором от имени пользователя.
Это важное дополнение к событиям аудита исправляет пробел в неоспоримости действий (nonrepudiation) для вашей программы соответствия требованиям и повышает надежность и полноту данных о событиях аудита GitLab.
Документация по событиям аудита и оригинальный тикет.
Аналитика цикла разработки: метрики для времени выполнения и времени цикла
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage
Две новые ключевые метрики в этой аналитике дают командам базу для измерения усилий по улучшению процесса, чтобы влияние изменений было нагляднее. Время выполнения — это время, прошедшее между запрошенным элементом и его поставкой. Время цикла — длина самого цикла разработки. Оптимизируя процесс создания продукта, команды лишний раз не перемещают проблему из одного места в другое, что ускоряет поставку.
|  |
Документация по аналитике цикла разработки и оригинальный тикет.
Приложение интеграции Okta SCIM для GitLab.com
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage
Теперь мы предлагаем приложение интеграции Okta SCIM для групп на Gitlab.com. Когда Okta SCIM настраивается для группы GitLab, членство в этой группе синхронизируется между GitLab и Okta. Это экономит время администратора группы, затрачиваемое на добавление и удаление пользователей.
Документация по настройке SCIM и оригинальный эпик.
Экспорт и импорт групп в пользовательском интерфейсе
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Manage
Ранее пользователи могли переносить группы только с помощью API экспорта и импорта: сначала требовалось создать файл экспорта, а затем снова с помощью API загрузить файл в нужный инстанс.
В качестве первого шага на пути к более удобному решению мы включили экспорт группы в пользовательском интерфейсе GitLab. Мы планируем добавить аналогичную функциональность для импорта в пользовательский интерфейс в течение нескольких следующих недель.
Документация по импорту и экспорту и оригинальный эпик.
Просмотр майлстоунов на дорожной карте
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Plan
Точное отслеживание состояния процесса работы необходимо, чтобы помочь командам не сбиться с пути. Теперь, просматривая свою дорожную карту, вы можете увидеть, как ваши эпики соотносятся с различными майлстоунами, помогая вам оценить, когда работа завершится, и определить, насколько проекты соответствуют ожидаемому графику.
Документация по дорожным картам и оригинальный тикет.
Перетаскивание тикетов между эпиками в дереве эпиков
(ULTIMATE, GOLD) Стадия цикла DevOps: Plan
Часто при организации или кураторстве эпика вам нужно переместить существующий тикет в другой эпик в дереве. Теперь вы можете сделать это с помощью перетаскивания, вместо того чтобы щелкать по нескольким вкладкам.
Документация по управлению эпиками и оригинальный тикет.
Управление дизайнами теперь в Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
В релизе 12.2 управление дизайнами началось с загрузки дизайнов и обсуждения интересующих мест в рамках GitLab Premium. С тех пор мы рассматривали как отдельных участников наших пользователей, занимающихся дизайном продуктов, а в 13.0 мы переместили эти две фичи в GitLab Core. Это согласуется с нашей моделью покупки для индивидуальных разработчиков. Мы ожидаем, что в будущем по мере развития управления дизайнами мы добавим другие замечательные командные функции, такие как согласование.
Так что теперь все пользователи могут загружать дизайны и давать обратную связь по дизайну в тикетах GitLab. Напоминаем, что вы найдете вкладку Дизайн (Design) рядом с вкладкой Обсуждение (Discussion) в любом тикете. Для начала попробуйте загрузить скриншот с помощью перетаскивания.
Документация по управлению дизайнами и оригинальный тикет.
Улучшенный редактор сниппетов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
С выпуском сниппетов с поддержкой версий в GitLab 13.0 мы обновили редактор сниппетов до более легкой версии редактора из нашей Web IDE. С помощью этого редактора пользователи смогут воспользоваться базовым дополнением кода и статическим анализом (линтингом) для некоторых языков. Мы также улучшили определение языка исходного кода для лучшей подсветки синтаксиса и добавили поддержку для всех наших тем подсветки синтаксиса. Эти улучшения облегчат редактирование и совместную работу над сниппетами.
Мы рады обеспечить согласованность редактора сниппетов и редактора в Web IDE. В следующем релизе мы добавим эти возможности также для нашего редактора одиночного файла и редактирования файла .gitlab-ci.yml.
Документация по сниппетам и оригинальный тикет.
WYSIWYG для редактора статических сайтов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Markdown — это мощный и эффективный синтаксис для создания веб-контента. Но даже опытные авторы контента в Markdown могут подзабыть некоторые из редко используемых параметров форматирования или с трудом пишут даже умеренно сложные таблицы с нуля. Некоторые работы удобнее выполнять с помощью визуального редактора «что видите, то и получите» (WYSIWYG).
GitLab 13.0 добавляет Markdown с WYSIWYG в редактор статических сайтов, включая такие параметры форматирования, как заголовки, полужирный шрифт, курсив, ссылки, списки, цитаты и блоки кода. Визуальный редактор также устраняет обременительную задачу редактирования таблиц в Markdown, позволяя редактировать строки, столбцы и ячейки так же, как в обычной электронной таблице. А для тех, кому удобнее писать сразу в Markdown, есть вкладка для переключения между WYSIWYG и обычным редактированием.
Документация по редактору статических сайтов и оригинальный тикет.
Фильтр Approved-by для мерж-реквестов
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Create
Утверждение мерж-реквеста требует, чтобы определенные люди одобрили изменения, прежде чем их можно будет смержить. При поиске в списке мерж-реквестов вы можете быстро найти, какие из них нуждаются в вашем одобрении, с помощью фильтра Утверждающие (Approvers). В GitLab 13.0 теперь вы также сможете найти любые ранее одобренные вами мерж-реквесты, используя новый фильтр Approved-By.
Документация по фильтрации мерж-реквестов и оригинальный тикет.
Поддержка родительских групп и пользователей в файле CODEOWNERS
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create
Группы можно использовать для организации пользователей в GitLab. Это позволяет легко делиться проектами, упоминать пользователей в комментариях или назначать несколько утверждающих для мерж-реквеста, не выбирая их по одному.
Группы и пользователей можно сделать владельцами кода, но при этом нельзя было использовать родительские группы (непосредственные и более верхнего уровня). Вернее, назначить родительскую группу из иерархии проекта в качестве владельца кода было можно, но от этого ничего не менялось.
GitLab 13.0 добавляет возможность включать пользователей и группы из родительской группы в файл CODEOWNERS проекта, обеспечивая больше гибкости при определении правил для владельцев кода.
Документация по определению владельцев кода и оригинальный тикет.
Наследование переменных окружения от других заданий
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Verify
Теперь можно передавать переменные окружения и другие данные между заданиями CI. Используя ключевое слово dependencies (или ключевое слово needs для конвейеров DAG), задание может наследовать переменные от других заданий, если они получены с помощью артефактов отчета dotenv. Это предлагает более изящный подход для обновления переменных между заданиями по сравнению с использованием артефактов или передачей файлов.
Документация по наследованию переменных окружения и оригинальный тикет.
Настраиваемый порог тестирования производительности браузера
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Verify
Тестирование производительности браузера позволяет пользователям до мержа с мастером обнаруживать, когда происходит ухудшение в их веб-приложении. Во многих случаях эта фича вызывает дополнительный визуальный шум и только загромождает страницу мерж-реквеста, даже для незначительных изменений. В этом майлстоуне у вас появилась возможность устанавливать порог ухудшения в качестве требования, которое определяет, надо ли показывать отчет о производительности.
Документация по настройке показа отчета о производительности и оригинальный тикет.
Просмотр более надежных данных в списке в пользовательском интерфейсе реестра пакетов
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package
До этого релиза в списочном представлении реестра пакетов отображался ограниченный объем информации, относящейся к пакетам. Хотя эта информация важна, в ней отсутствовали ключевые метаданные, такие как версия, ветка и коммит.
В 13.0 мы обновили дизайн этой страницы, добавив в него дополнительные метаданные, чтобы помочь вам найти искомый пакет и убедиться, что он собран правильно. В дополнение к имени пакета, теперь вы можете увидеть версию, тип и многое другое. Посмотрите видео для примера и начните использовать эту фичу сегодня.
Документация по просмотру дополнительной информации о пакете и оригинальный тикет.
Просмотр всех ваших пакетов Python в одном месте с помощью реестра пакетов GitLab
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package
Пользовательский интерфейс реестра пакетов GitLab позволяет вам подтвердить, что ваши пакеты были собраны правильно, и устранить неполадки, если что-то пошло не так. Однако MVC нового репозитория PyPI, запущенного в 12.10, не включал эту функциональность.
В версии 13.0 мы добавили репозиторий PyPI в пользовательский интерфейс реестра пакетов. Теперь вы можете просматривать и загружать пакеты PyPI вашего проекта или группы и проверять метаданные и правильность сборки пакета. Вы также можете скопировать команды настройки и установки для более эффективного совместного использования и разработки. Если пакет был собран с использованием конвейера GitLab, вы сможете просмотреть и связать его с конвейером, а также с коммитом, который использовался для публикации пакета.
Документация по репозиторию PyPI и оригинальный тикет.
Поддержка API для списков переключаемых фич
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release
В рамках нашей поддержки списков переключаемых фич мы добавили поддержку API, позволяющего создавать, редактировать и удалять их. Это облегчит автоматизацию управления и синхронизации этих списков между различными системами.
Документация по спискам переключаемых фич и оригинальный тикет.
Определите правила, чтобы важные образы никогда не удалялись
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package
Ранее при использовании правила истечения срока действия образов в GitLab невозможно было выразить что-то вроде «несмотря ни на что, не удалять этот тег». Это вносит риск в процесс удаления, поскольку могут быть удалены образы release или master, которые должны сохраняться.
В 13.0 теперь вы можете обновить правило истечения срока действия для вашего проекта, чтобы идентифицировать образы, которые вы не хотите удалять никогда. Просто включите это правило и используйте регулярные выражения, чтобы определить образ, который вы хотите сохранить.
Документация по правилам истечения срока действия и оригинальный тикет.
Используйте облачные пакеты сборки для Auto DevOps (бета-версия)
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure
Облачные пакеты сборки являются следующей итерацией пакетов сборки. В то время как GitLab в настоящее время по умолчанию использует пакеты сборки Herokuish, мы намерены перевести Auto DevOps на облачные пакеты сборки, когда проект созреет, чтобы предоставить нашим пользователям надежное и хорошо поддерживаемое решение. В этом релизе вы можете выбрать использование бета-версии облачных нативных пакетов сборки в конвейерах Auto DevOps, установив переменную CI AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED.
Документация по облачным пакетам сборки для Auto DevOps и оригинальный тикет.
Агрегирование оповещений из внешних инструментов в GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
При реагировании на предупреждения респондентам необходим единый интерфейс, объединяющий IT-оповещения, поступающие из нескольких источников. Новый список оповещений позволяет быстро и интуитивно сортировать оповещения, чтобы в первую очередь найти и проанализировать наиболее важные проблемы. Вы можете найти список предупреждений в Операции > Оповещения (Operations > Alerts).
Документация по списку оповещений и оригинальный тикет.
Добавьте часто используемые панели мониторинга в избранное
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
В GitLab 13.0 вы сможете добавлять свои часто используемые панели мониторинга в избранное, нажимая кнопку Star. Отмеченная звездочкой панель отображается в начале результатов поиска, что экономит ваше время.
Документация по добавлению панелей мониторинга в избранное и оригинальный эпик.
Отображение графиков в полноэкранном режиме
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Monitor
В GitLab 13.0 теперь можно отображать графики метрик в полноэкранном режиме, что позволяет более подробно рассмотреть информацию на них при сортировке инцидентов.
Документация по разворачиванию панели Prometheus и оригинальный эпик.
Анонимизация на страницах статуса
(ULTIMATE, GOLD) Стадия цикла DevOps: Monitor
Когда группа реагирования на инциденты делится обновлениями и изменениями статуса, описание инцидента публикуется в открытом доступе, но все имена пользователей и групп в описаниях тикетов анонимизируются для защиты конфиденциальности отдельных лиц и групп.
Документация по публикации инцидентов и оригинальный тикет.
Просмотр списка просканированных DAST ресурсов
ULTIMATE, GOLD) Стадия цикла DevOps: Secure
DAST проверяет ваше работающее веб-приложение на наличие известных уязвимостей во время выполнения, начиная с каждого мерж-реквеста. DAST сканирует много ресурсов, но точно узнать, какие именно, раньше было невозможно.
GitLab 13.0 предоставляет полный список ресурсов, которые были просканированы DAST. Теперь вы можете оценить DAST-сканирование, чтобы убедиться, что приложение защищено со всех сторон. Для упрощения дальнейшего анализа можно загрузить списки сканирования непосредственно с экрана результатов.
Документация по списку просканированных объектов и оригинальный тикет.
Интеграции SIEM для правил контейнерных сетей
(ULTIMATE, GOLD) Стадия цикла DevOps: Defend
Мы представляем новую интеграцию SIEM для правил сетевой безопасности контейнеров. Интеграция позволяет пользователям экспортировать свои логи Cilium в SIEM или в централизованное решение для логирования, чтобы они могли просматривать любые аномалии, обнаруженные их сетевыми правилами. Просмотр журналов также помогает пользователям тестировать и настраивать свои сетевые правила, чтобы снизить вероятность ложных срабатываний. Интеграцию SIEM можно настроить на странице Операции > Kubernetes (Operations > Kubernetes).
Документация по Fluentd и оригинальный тикет.
Оперативная информация о базе данных уязвимостей
(ULTIMATE, GOLD) Стадия цикла DevOps: Secure
Мы знаем, что понимание возможностей сканирований GitLab важно для того, чтобы вы чувствовали себя в безопасности. В этом релизе мы представляем новую страницу с дополнительной информацией о базе данных уязвимостей, используемой нашими сканерами.
На этой странице вы можете получить информацию о том, что мы ищем, когда мы в последний раз обновляли нашу базу данных, а также найти конкретные уязвимости, которые вас беспокоят.
Документация по базе данных уязвимостей и оригинальный тикет.
PostgreSQL 11 теперь минимально необходимая версия для установки GitLab
(CORE, STARTER, PREMIUM, ULTIMATE) Доступность
Теперь минимальной требуемой версией PostgreSQL для всех пользовательских инстансов стала PostgreSQL 11. PostgreSQL версий 9.6 и 10 были удалены в GitLab 13.0. Это обновление позволяет нам начать вводить улучшения производительности на основе функций разбиения на разделы, которые были добавлены в PostgreSQL 11. Мы планируем поддерживать PostgreSQL 11 на протяжении всей серии релизов GitLab 13.x. Поддержка PostgreSQL 12 будет добавлена в ближайшее время. Посмотрите важные замечания по обновлению для получения инструкций по обновлению PostgreSQL.
Документация по настройке баз данных и оригинальный эпик.
Улучшена производительность репликации Geo для артефактов заданий, загрузок и файлов LFS
(PREMIUM, ULTIMATE) Доступность
Чтобы определить, что нужно реплицировать с первичной базы данных, Geo сравнивает базу данных отслеживания с вторичной базой данных только для чтения. Если запросы к базе данных Geo выполняются слишком долго, то данные не могут быть успешно реплицированы. В GitLab 13.0 мы используем новый подход к синхронизации артефактов заданий и загрузок, тем самым исключая возможность таймаутов базы данных. Мы также улучшили производительность запросов к базе данных для извлечения артефактов заданий, объектов LFS и загрузок, когда эти файлы хранятся локально. Это повышает общую масштабируемость и производительность GitLab Geo.
Эти итерации приближают нас к устранению зависимости Geo от сторонних оболочек данных, которые были добавлены для повышения производительности, но делают Geo более сложно устроенным и затрудняют его обслуживание.
Документация по репликации Geo и оригинальный эпик.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 13.0 released with Gitaly Clusters, Epic Hierarchy on Roadmaps, and Auto Deploy to ECS.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.
