Вышел релиз GitLab 12.10 с управлением требованиями и автоматическим масштабированием CI на AWS Fargate

Картинка для привлечения внимания

GitLab 12.10 помогает командам контролировать и улучшать соответствие требованиям с новой фичей «управление требованиями», уменьшать время цикла и ускорять поставку программного обеспечения благодаря CI с автоматическим масштабированием на AWS Fargate и более эффективно управлять портфелем проектов с отображением состояния тикетов и эпиков (в русской локализации GitLab «цели»).

Соответствовать требованиям стало проще

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

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

Также мы подготовили новый шаблон проекта для протокола аудита HIPAA в помощь проектам, которые подлежат аудиту и соблюдению требований HIPAA. С новым релизом станет проще защищать свои секретные ключи с помощью улучшенной интеграции хранилища HashiCorp, что поможет поддерживать ваши проекты в соответствии с вашими правилами безопасности.

Сократите время цикла и ускорьте поставку на AWS

Меньше всего вам нужно еще одно узкое место, которое потенциально может замедлить поставку. Именно поэтому мы поддерживаем автоматическое масштабирование обработчиков заданий CI от GitLab уже очень, очень долгое время. В GitLab 12.10 мы расширяем наши возможности автоматического масштабирования на AWS Fargate до масштабирования обработчиков заданий, чтобы конвейеры (в русской локализации GitLab «сборочные линии») могли эффективно масштабироваться для удовлетворения существующего спроса. Кстати об AWS, теперь вы сможете быстрее и проще настраивать ваши приложения с помощью предопределенных переменных развертывания AWS. Помимо переменных развертывания, GitLab также помогает с проверкой формата.

Управляйте проектами эффективнее

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

И это еще не все!

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

Просим вас оставить фидбек по релизу (на английском) и приглашаем на наши встречи.

GitLab MVP badge

MVP этого месяца — Дмитрий Чепуровский

Дмитрий внес большой вклад в этот релиз, добавив поддержку веб-сервера Puma в наш Helm chart unicorn (скоро его название изменится на ‘webservice’). Это дает пользователям GitLab Helm chart возможность использовать Puma вместо Unicorn. В ходе тестирования мы отметили 40%-ное снижение использования памяти при использовании Puma в качестве веб-сервера. Дмитрий, мы очень ценим ваше сотрудничество и огромный вклад в добавление Puma к нашим нативным облачным инструментам.

Посмотрите соответствующий эпик и начните использовать Puma уже сегодня! Спасибо Дмитрию за этот вклад и огромную работу.

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

Создавайте и просматривайте требования в GitLab

(ULTIMATE, GOLD) Стадия цикла DevOps: “Plan”

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

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

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

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

Получение секретных ключей для CI/CD из хранилища HashiCorp

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”

В этом релизе GitLab добавляет поддержку легковесной аутентификации JSON Web Token (JWT) для интеграции с вашим существующим хранилищем HashiCorp. Теперь вы сможете легко предоставлять секретные ключи для заданий CI/CD, используя метод JWT-аутентификации HashiCorp вместо того, чтобы вручную передавать их в качестве переменной в GitLab.

Retrieve CI/CD secrets from HashiCorp Vault

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

Отслеживание состояния эпиков и тикетов

(ULTIMATE, GOLD) Стадия цикла DevOps: “Plan”

Управлять многочисленными эпиками среди нескольких групп и проектов бывает непросто. Чтобы помочь пользователям отслеживать состояние проектов и рабочий процесс, GitLab предлагает возможность отмечать состояние отдельных тикетов красным, желтым или зеленым цветом, что приведет к изменению состояния эпика в вашем дереве эпиков. Назначьте тикету состояние По плану (On track) — зеленый цвет, Требует внимания (Needs attention) — желтый или В зоне риска (At risk) — красный и посмотрите сводный отчет о состоянии на уровне эпика. Теперь вы сможете быстро посмотреть и проанализировать, где работа находится под угрозой, чтобы вовремя открыть нужные обсуждения и продолжить работу в соответствии с планом.

Epic and Issue Health Tracking

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

Импорт тикетов из Jira в GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”

До сих пор переносить тикеты из Jira в GitLab можно было только вручную, с помощью нашего CSV-импортера или с помощью вашей собственной утилиты для миграции. В GitLab 12.10 мы представляем MVC автоматического импорта ваших тикетов Jira в GitLab. Это первое из многих запланированных улучшений, позволяющих сделать переход с Jira на GitLab максимально простым.

Чтобы начать работу, настройте интеграцию Jira в вашем проекте GitLab, нажмите на значок импорта в верхней части списка тикетов вашего проекта и выберите Импорт из Jira.

Import Issues from Jira to GitLab

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

Автоматическое масштабирование CI-заданий GitLab на AWS Fargate

(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Verify”

Автоматическое масштабирование обработчика заданий GitLab реагирует на потребности заданий CI, предоставляя новые виртуальные машины, размещенные в облаке. Однако, несмотря на то, что эта модель достаточна для определенных случаев использования, в некоторых случаях пользователи также хотят воспользоваться возможностями облачного управления контейнерами для выполнения CI/CD заданий в GitLab. Теперь вы можете автоматически масштабировать GitLab CI на AWS Fargate с помощью MVC драйвера для AWS Fargate. В этой новой модели автоматического масштабирования наш драйвер для AWS Fargate автоматически запускает каждую сборку в отдельном изолированном контейнере на Elastic Container Service (ECS) от Amazon, используя заданный пользователем образ контейнера.

Autoscaling GitLab CI jobs on AWS Fargate

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

Легко настраиваемые переменные развертывания AWS

(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Release”

Применять необходимые переменные окружения при развертывании в AWS должно быть максимально удобно. Теперь можно выбрать предопределенные переменные AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и AWS_DEFAULT_REGION из списка переменных ключей окружения. Вы также сможете убедиться, что переменные, которые вы вводите, имеют правильный формат.

Easy to configure AWS deployment variables

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

Присоединяйте перечни задач к Релизам

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”

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

Link runbooks and assets to a Release

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

Усовершенствованные рабочие процессы безопасности для использования в офлайн-окружениях

(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”

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

Новая документация описывает высокоуровневый рабочий процесс, необходимый для сканирования безопасности в офлайн-окружении. Мы также добавили особые инструкции по работе на странице документации каждого конкретного сканера.

Мы продолжим добавлять поддержку автономного сканирования безопасности в будущих релизах, предоставляя поддержку дополнительных языков, инструментов и вариантов использования.

Enhanced Secure workflows for use in offline environments

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

Страница статуса

(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”

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

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

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

Status Page

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

Сборка, публикация и распространение пакетов Python в репозитории GitLab PyPI

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”

Разработчикам Python нужен удобный механизм создания, обмена и использования пакетов, которые содержат скомпилированный код и другое содержимое, в нужных проектах. PyPI — проект с открытым исходным кодом, поддерживаемый Python Packaging Authority, — является стандартом по определению, созданию, хостингу и использованию пакетов Python.

В GitLab 12.10 мы с гордостью представляем репозитории PyPI, встроенные напрямую в GitLab! Теперь у разработчиков будет более удобный способ публиковать Python-пакеты своих проектов. Интеграция GitLab с PyPI предоставит централизованную локацию для хранения и просмотра этих пакетов в том же месте, где находится их исходный код и конвейеры.

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

Build, publish, and share Python packages to the GitLab PyPI Repository

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

Статистика по правилам сетевой безопасности реестра контейнеров

(ULTIMATE, GOLD) Стадия цикла DevOps: “Defend”

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

Статистика по правилам реестра контейнеров появится на новой странице Мониторинг угроз (Threat Monitoring) в пункте меню Безопасность и соответствие требованиям (Security & Compliance). По умолчанию эти данные отображаются за 30-дневный период.

Container Network Policies Statistics Reporting

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

Управление режимами логирования и блокировки файервола веб-приложений

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Defend”

Для более удобной настройки правил для избежания ложноположительных и ложноотрицательных результатов вы можете глобально переключить ваш файервол веб-приложений в режим Логирование (Logging) или Блокировка (Blocking) на странице Операции -> Kubernetes (Operations -> Kubernetes).

Web Application Firewall (WAF) Controls for Logging and Blocking Modes

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

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

Временная метка для наблюдений по Релизам

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”

В версии 12.6 GitLab представил модернизированный подход к сбору всей необходимой информации для поддержки соответствия требованиям и аудита в рамках релиза. В 12.10 мы добавили фичу, которая будет создавать временную метку с датой сбора наблюдений Релиза рядом со ссылкой на скачивание хэша наблюдений. Это позволит членам команды с ролью auditor с легкостью сравнивать, как меняются наблюдения по релизу с течением времени вместо того, чтобы писать скрипт для сборки и сравнения каждого фрагмента наблюдений.

Compare Release Evidence over time

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

Новый шаблон проекта для протокола аудита HIPAA

(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”

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

GitLab теперь поддерживает протокол аудита HIPAA с новым шаблоном для версии Enterprise. Для помощи в соблюдении требований GitLab предоставляет новый шаблон для создания проектов со 180 тикетами, которые распределены в соответствии с протоколом аудита HIPAA. Каждый тикет служит как контрольный журнал для каждого протокола HIPAA и может помочь командам оставаться на связи при управлении программами по соблюдению требований HIPAA в GitLab.

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

Настройка даты истечения срока действия ключа SSH

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”

Организациям, нацеленным на соблюдение требований, нужен способ контролировать доступ к их окружению GitLab через SSH. Ключи SSH, как правило, создаются без срока действия. И это является проблемой для организаций с правилами управления доступом и/или данными для доступа, которые требуют определения даты истечения срока действия для всех данных доступа к учетным записям. С этим релизом GitLab поддерживает настройку срока ключей SSH через пользовательский интерфейс GitLab.

Optional SSH key expiration date

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

MVC для обзора активности в группе

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”

Руководителям разработки и администраторам GitLab важно знать, как их команды используют GitLab. С этим MVC мы добавили три счетчика на страницу группы: счетчики мерж-реквестов, тикетов и пользователей, добавленных в группу, — все это за последние 90 дней. Эта фича доступна в бета-версии.

Group-level activity overview MVC

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

Сортировка событий в тикетах и мерж-реквестах по недавней активности

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”

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

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

View Issue and MR feed by newest activity first

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

Миниатюры дизайнов

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”

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

Мы протестировали мокап домашней страницы GitLab, изображение размером 1222 на 5113 пикселей и занимающее 2.6 Мб. С генерацией миниатюры размер изображения уменьшается до 0.018 Мб, что на ~99.9% меньше оригинала!

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

Иконки для расширений файлов в репозитории

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”

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

Кроме того, теперь стиль иконок в репозитории согласуется со стилем Web IDE и дерева файлов мерж-реквеста. Наслаждайтесь!

Repository file icons based on file extension

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

Высокая доступность для Gitaly (бета)

(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Create”

Для разработчиков и компаний критически важно иметь доступ к репозиториям Git. Если происходит остановка в работе, разработчики не могут загружать код и развертывания будут заблокированы. Для предотвращения остановок, GitLab можно запускать в режиме высокой доступности (highly available, HA). Рекомендуемый подход сейчас использует протокол Network File System (NFS), но это добавляет значительную задержку для каждой операции чтения и записи, что серьезно влияет на производительность GitLab.

В GitLab 12.10 Gitaly предлагает бета-версию поддержки высокой доступности без использования NFS. Хотя потеря данных маловероятна, фичу пока не рекомендуется использовать в окружениях для продакшена. В этом релизе очередь репликации и состояние лидера переместились в базу данных PostgreSQL. Ранее очередь репликации и состояние лидера хранились в памяти в прокси или роутере Praefect. Это не позволяло делать настройки, использующие несколько нод Praefect и могло привести к потере данных, если Praefect был перезапущен до того, как очередь репликации закончилась.

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

High Availability for Gitaly (beta)

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

Фильтр по названию пакета для реестра пакетов

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”

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

В GitLab 12.10 вы сможете фильтровать по имени (name), чтобы быстро находить нужные вам пакеты.

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

Уровни опасности для уязвимостей при сканировании зависимостей

(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”

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

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

Оповещения в GitLab Core

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

Одна из важнейших частей мониторинга и наблюдения за производительностью системы и приложений — это оповещения, которые вы получаете, когда что-то идет не так. Без них невозможно соблюдать DevOps и эффективно реагировать на превышение критических порогов в службах. Эти возможности необходимы любой команде разработчиков, и мы хотим, чтобы наше управление оповещениями было доступно любому, кто использует GitLab. Как часть нашего подарка на 2020 год, мы переместили оповещения стадии мониторинга из GitLab Ultimate в GitLab Core. Начиная с GitLab 12.10 все пользователи смогут создавать IT-оповещения в графиках на панели метрик и получать оповещения в GitLab через базовую конечную точку REST.

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

Автоматическое добавление метрик в тикеты GitLab для оповещений Prometheus

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

При обработке инцидентов графики помогают вам визуализировать, что пошло не так, ускоряя расследование и решение проблемы. В версии 12.9 GitLab начал автоматически встраивать релевантные графики во все тикеты по инцидентам, которые были созданы из оповещений Prometheus, настроенных GitLab. Теперь мы расширили эту фичу для работы с тикетами, генерируемыми из всех оповещений Prometheus, которые получает GitLab, вне зависимости от того, были они настроены в GitLab или где-либо еще.

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

Фильтр для поиска по логам подов

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

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

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

Поддержка настраиваемых временных интервалов в графиках метрик

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

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

Support custom intervals in metrics charts

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

Легкое удаление неиспользуемых файлов LFS

(CORE, STARTER, PREMIUM, ULTIMATE) “Доступность”

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

В этом релизе мы добавили две задачи Rake: gitlab:cleanup:orphan_lfs_file_references и gitlab:cleanup:orphan_lfs_files, которые позволяют удалять файлы LFS из отдельных проектов. Задачи Rake можно запускать в отдельных проектах и по расписанию.

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

Сокращение размера индекса расширенного глобального поиска примерно на 50%

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) “Доступность”

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

Мы заново оценили, какой контент должен быть проиндексирован, и обновили настройки index_options для нашей конфигурации расширенного глобального поиска. На GitLab.com мы увидели почти 50%-ное снижение нашего продакшн индекса Elasticsearch. Это изменение должно облегчить начало работы с расширенным глобальным поиском и поможет уменьшить накладные расходы при использовании расширенного глобального поиска в GitLab.

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

Переход на обычный SQL для схемы GitLab

(CORE, STARTER, PREMIUM, ULTIMATE) “Доступность”

GitLab 12.10 перешел от использования schema.rb к structure.sql для управления схемой базы данных. Переход на обычный SQL в structure.sql позволяет GitLab использовать команды, специфичные для PostgreSQL, например разбиение на разделы.

Авторы и администраторы могут захотеть отслеживать изменения, если им нужно работать с миграциями. Изменения в structure.sql будут выполнены автоматически, не требуя никаких дополнительных действий.

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

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

(ULTIMATE, GOLD) Стадия цикла DevOps: “Manage”

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

Теперь можно отмечать, что проект содержит определенные правила соответствия требованиям. Для этого надо перейти в Настройки (Settings) проекта, затем в разделе Основныe (General) выбрать Правила соответствия (Compliance framework) из выпадающего меню. Эта фича закладывает основу для упрощения управления соответствием проекта требованиям в будущем.

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

Панель мониторинга соответствия показывает результаты конвейера для последнего принятого мерж-реквеста

(ULTIMATE, GOLD) Стадия цикла DevOps: “Manage”

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

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

Compliance dashboard shows pipeline result for the most recent, merged MR

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

Продление срока действия токена доступа на GitLab.com

(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”

Начиная с 12.10 клиенты GitLab.com могут также ограничить срок действия токенов личного доступа в управляемых группой учетных записях, аналогично самоуправляемым инстансам GitLab.

В разделе Общие (General) настроек вашей группы вы можете указать срок жизни для токенов личного доступа, созданных членами учетной записи, управляемой группой. Это правило будет применяться только к пользователям этой группы.

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

Используйте «копировать/вставить» для загрузки изображения на вкладку Дизайн

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”

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

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

Отслеживание активности в вики

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”

До GitLab 12.9, когда вы вносили свой вклад в вики-контент, это не отображалось как ваша активность в GitLab. Начиная с этого релиза вы увидите все вики-вклады на страницах проектов, групп и пользователей. Теперь вы можете отслеживать изменения в вики, а редакторы вики будут отмечены за их вклад!

Tracking Wiki activity

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

Кэширование Git-файла info/refs

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”

При получении изменений из репозитория Git сервер объявляет список всех ветвей и тегов в репозитории, известный как refs. В некоторых инстансах мы наблюдали, что до 75% всех запросов к веб-серверу GitLab являются запросами этого списка. В лучшем случае, когда все ссылки упакованы (packed), это недорогая операция. Однако, когда есть неупакованные (unpacked) ссылки, Git должен проверить их все. Это приводит к дополнительной нагрузке на обращение к диску, что медленно, когда используется хранилище с большими задержками вроде NFS.

В GitLab 12.10 файл info/refs кэшируется для повышения производительности объявления ссылок и уменьшения нагрузки на Gitaly в ситуациях, когда ссылки очень часто запрашиваются. При тестировании этой фичи на GitLab.com мы наблюдали, что операции чтения происходят в 10 раз чаще операций записи, а медианная задержка уменьшилась на 70%. Для инстансов GitLab, использующих NFS для хранения репозитория Git, мы ожидаем еще большее улучшение.

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

Шаблон проекта со встроенным редактором статических сайтов

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”

Хостинг статических веб-сайтов с помощью GitLab Pages — это простой и быстрый способ запустить ваш сайт. Однако редактирование контента, который заполняет ваш статический сайт, часто требует настройки сложных локальных сред разработки, понимания базовой архитектуры проекта и знакомства с синтаксисом Markdown. Для некоторых это становится препятствием для работы.

Мы делаем первый шаг к созданию первоклассного опыта редактирования статического контента сайта. Это облегчит совместную работу над контентом и не потребует от вас знания языков программирования и даже знания Git. GitLab теперь включает новый шаблон проекта, который создает статический сайт. Этот сайт изначально поддерживает Middleman, предварительно настроен для размещения на страницах GitLab, и включает содержимое, которое можно редактировать в новом, оптимизированном редакторе статического сайта. После развертывания сайта просто нажмите на ссылку «Редактировать эту страницу», отображаемую на каждой странице, и это запустит наш новый редактор, который не показывает посторонний интерфейс, а полностью фокусируется на содержимом страницы. Когда вы закончите, одним щелчком мыши создайте новую ветку и мерж-реквест для ваших изменений.

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

Просмотр образов Docker в реестре контейнеров на уровне группы

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”

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

С релизом 12.10 вы теперь можете просматривать все образы своей группы в приложении GitLab. Теперь вы можете делиться, открывать и управлять всеми своими образами в едином месте.

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

Отключение отдельных правил в DAST

(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”

Как инструмент — «черный ящик», сканирование DAST ничего не знает о базовой архитектуре сайта или приложения. Это может привести к ложным срабатываниям, которые пользователь сразу распознает как ложные. Например сканирование DAST, сообщающее о возможной уязвимости внедрения SQL, когда в архитектуре приложения нет базы данных SQL. Из-за этой проблемы GitLab 12.10 предлагает возможность отключения определенных правил с помощью переменной DAST_EXCLUDE_RULES. Она принимает список разделенных запятыми идентификаторов правил уязвимости, которые следует исключить из сканирования. С помощью этой переменной вы сможете лучше адаптировать сканирование к целевому приложению, чтобы получать меньше ложных срабатываний.

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

Используйте интерфейс GitLab для удаления окружения

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”

Эта фича позволяет пользователям легко администрировать свои окружения с помощью пользовательского интерфейса GitLab, а не через API. Управление окружениями через пользовательский интерфейс экономит время и помогает пользователям, предпочитающим проводить свое время в интерфейсе GitLab.

Use GitLab UI to delete an environment

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

Сворачивание развернутых графиков в тикетах

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

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

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

Отображение метрик в виде гистограмм

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

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

Display your metrics with bar charts

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

Интервал времени в URL для графиков метрик

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

При просмотре графиков метрик обновление интервала времени теперь также обновляет URL-адрес графика, позволяя вам легко делиться ссылками на определенные временные рамки и добавлять их в закладки.

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

Geo перенаправляет запросы HTTP(S) к несинхронизированным репозиториям на основную ноду

(PREMIUM, ULTIMATE) “Доступность”

Geo поддерживает выборочную синхронизацию проектов, что позволяет системным администраторам выбирать подмножество данных, которое реплицируется на вторичную ноду Geo. До сих пор пользователи, пытавшиеся получить доступ к несинхронизированным репозиториям на вторичной ноде, получали сообщение об ошибке, что проект недоступен. Это могло происходить из-за выборочной синхронизации или из-за задержки репликации. Это сбивало с толку пользователей и нарушало их рабочий процесс Git.

В GitLab 12.10 любые запросы Git, сделанные через HTTP(S) к несинхронизированной вторичной ноде Geo, будут перенаправлены на первичную ноду, чтобы пользователи все-таки могли получить доступ к репозиторию. Это означает, что пользователям не нужно будет знать, что реплицируется, а что нет, — Geo попытается выполнить запрос в любом случае. Поддержка проксирования SSH-операций в Git будет доступна в GitLab 13.0.

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

Подсветка найденного кода в глобальном поиске

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Доступность”

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

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

Огромное спасибо @terales за эту фичу!

Highlight code results in Global Search

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


Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.10 released with Requirements Management and Autoscaling CI on AWS Fargate.

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