GitLab 12.10 помогает командам контролировать и улучшать соответствие требованиям с новой фичей «управление требованиями», уменьшать время цикла и ускорять поставку программного обеспечения благодаря CI с автоматическим масштабированием на AWS Fargate и более эффективно управлять портфелем проектов с отображением состояния тикетов и эпиков (в русской локализации GitLab «цели»).
Обеспечение соответствия требованиям — часто встречающаяся задача во многих крупных организациях, где команды и проекты должны продемонстрировать, что они следовали всем процессам и процедурам организации и выполнили то, что на самом деле требовалось. Действительно ли проект соответствует бизнес-требованиям — широко распространенный вопрос, и с 12.10 мы представляем управление требованиями как отдельную категорию в GitLab для помощи в определении, отслеживании и управлении бизнес-требованиями.
Кроме того, в GitLab 12.10 стало проще продемонстрировать соответствие проекта и релиза требованиям, так как больше нет необходимости использовать скрипты для сравнения материалов релизов во времени. Это поможет командам документировать и подтверждать, что проект выполнен в соответствии с требованиями. Новые метки соответствия требованиям для проектов позволят организациям легко указать, что для конкретного проекта требуется соблюдение особых требований по соответствию стандартам.
Также мы подготовили новый шаблон проекта для протокола аудита HIPAA в помощь проектам, которые подлежат аудиту и соблюдению требований HIPAA. С новым релизом станет проще защищать свои секретные ключи с помощью улучшенной интеграции хранилища HashiCorp, что поможет поддерживать ваши проекты в соответствии с вашими правилами безопасности.
Меньше всего вам нужно еще одно узкое место, которое потенциально может замедлить поставку. Именно поэтому мы поддерживаем автоматическое масштабирование обработчиков заданий CI от GitLab уже очень, очень долгое время. В GitLab 12.10 мы расширяем наши возможности автоматического масштабирования на AWS Fargate до масштабирования обработчиков заданий, чтобы конвейеры (в русской локализации GitLab «сборочные линии») могли эффективно масштабироваться для удовлетворения существующего спроса. Кстати об AWS, теперь вы сможете быстрее и проще настраивать ваши приложения с помощью предопределенных переменных развертывания AWS. Помимо переменных развертывания, GitLab также помогает с проверкой формата.
Управление несколькими проектами и связанными с ними тикетами — настоящее искусство. Со всей информацией, которую нужно отслеживать, бывает трудно понять, где могут возникнуть проблемы. С релизом 12.10 стало проще отслеживать и делиться состоянием тикетов, что позволит легко визуализировать общее состояние эпика. Кроме того, мы упрощаем импорт тикетов из Jira в GitLab, так что команды смогут тратить меньше времени на переключение между инструментами и больше времени на создание хорошего программного обеспечения.
В кратком описании релиза никогда не хватает места, чтобы выделить все классные новые фичи. Вот еще пара крутых фич, на которые стоит взглянуть: репозиторий Python PyPI и сортировка по недавней активности в тикетах и мерж-реквестах (в русской локализации GitLab «запросы на слияние»).
Просим вас оставить фидбек по релизу (на английском) и приглашаем на наши встречи.
Дмитрий внес большой вклад в этот релиз, добавив поддержку веб-сервера Puma в наш Helm chart unicorn
(скоро его название изменится на ‘webservice’). Это дает пользователям GitLab Helm chart возможность использовать Puma вместо Unicorn. В ходе тестирования мы отметили 40%-ное снижение использования памяти при использовании Puma в качестве веб-сервера. Дмитрий, мы очень ценим ваше сотрудничество и огромный вклад в добавление Puma к нашим нативным облачным инструментам.
Посмотрите соответствующий эпик и начните использовать Puma уже сегодня! Спасибо Дмитрию за этот вклад и огромную работу.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Plan”
Это первый шаг к управлению соответствию требованиями внутри GitLab. В этой начальной версии у пользователей появилась возможность создавать и просматривать требования на уровне проекта.
Мы часто слышим о трудностях, связанных с внешними инструментами управления требованиями: сложными интеграциями, множеством различных инструментов и запутанными рабочими процессами. Мы верим в силу одного приложения и потому предлагаем возможность хранить все требования, проекты, код и тесты в одном окружении. Система управления требованиями в GitLab еще на стадии развития, скоро появится поддержка отслеживаемости по всем артефактам, что позволит создать непрерывный рабочий процесс, визуально демонстрирующий целостность и соответствие нормативным требованиям.
Для получения дополнительной информации и совместной работы с нами по новой системе управления требованиями загляните в раздел про развитие категории «Управление требованиями».
Документация по управлению требованиями проекта и оригинальный эпик.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
В этом релизе GitLab добавляет поддержку легковесной аутентификации JSON Web Token (JWT) для интеграции с вашим существующим хранилищем HashiCorp. Теперь вы сможете легко предоставлять секретные ключи для заданий CI/CD, используя метод JWT-аутентификации HashiCorp вместо того, чтобы вручную передавать их в качестве переменной в GitLab.
Документация по аутентификации с хранилищем HashiCorp и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Plan”
Управлять многочисленными эпиками среди нескольких групп и проектов бывает непросто. Чтобы помочь пользователям отслеживать состояние проектов и рабочий процесс, GitLab предлагает возможность отмечать состояние отдельных тикетов красным, желтым или зеленым цветом, что приведет к изменению состояния эпика в вашем дереве эпиков. Назначьте тикету состояние По плану (On track) — зеленый цвет, Требует внимания (Needs attention) — желтый или В зоне риска (At risk) — красный и посмотрите сводный отчет о состоянии на уровне эпика. Теперь вы сможете быстро посмотреть и проанализировать, где работа находится под угрозой, чтобы вовремя открыть нужные обсуждения и продолжить работу в соответствии с планом.
Документация по состоянию в тикетах и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
До сих пор переносить тикеты из Jira в GitLab можно было только вручную, с помощью нашего CSV-импортера или с помощью вашей собственной утилиты для миграции. В GitLab 12.10 мы представляем MVC автоматического импорта ваших тикетов Jira в GitLab. Это первое из многих запланированных улучшений, позволяющих сделать переход с Jira на GitLab максимально простым.
Чтобы начать работу, настройте интеграцию Jira в вашем проекте GitLab, нажмите на значок импорта в верхней части списка тикетов вашего проекта и выберите Импорт из Jira.
Документация по импорту из Jira и оригинальный эпик.
(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, используя заданный пользователем образ контейнера.
Документация по драйверу и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Release”
Применять необходимые переменные окружения при развертывании в AWS должно быть максимально удобно. Теперь можно выбрать предопределенные переменные AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
и AWS_DEFAULT_REGION
из списка переменных ключей окружения. Вы также сможете убедиться, что переменные, которые вы вводите, имеют правильный формат.
Документация по проверке переменных AWS и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Менеджеры по релизам и сборкам часто отвечают за несколько действий за пределами GitLab для того, чтобы эффективно выпускать релизы. GitLab работает над тем, чтобы сделать страницу Релиза единым источником информации обо всем, что касается ваших релизов. Мы добавили возможность добавлять перечни задач (runbook) к материалам Релиза, так что теперь вы сможете легко отслеживать все связанные действия и контролировать, как они выполняются.
Документация по материалам релиза и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Сканерам безопасности GitLab необходимо подключение к интернету для загрузки обновлений и последних сигнатур. GitLab 12.10 значительно упрощает использование этих сканеров при работе с пользовательскими инстансами GitLab в автономном режиме или с ограниченным подключением к интернету. Несколько корректировок основных заданий сканера обеспечивают поддержку этого рабочего процесса.
Новая документация описывает высокоуровневый рабочий процесс, необходимый для сканирования безопасности в офлайн-окружении. Мы также добавили особые инструкции по работе на странице документации каждого конкретного сканера.
Мы продолжим добавлять поддержку автономного сканирования безопасности в будущих релизах, предоставляя поддержку дополнительных языков, инструментов и вариантов использования.
Документация по проверке безопасности в оффлайн-окружениях и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
Когда ваш сервис не работает или работает плохо, вашим главным приоритетом становится его восстановление. В то же время вы должны информировать клиентов и заинтересованные стороны о прогрессе в устранении неполадок. Если вы будете держать их в неведении, вы будете получать много гневных писем. Пользователи полагаются на страницы с информацией о состоянии, чтобы убедиться, что провайдеры знают о проблемах, и узнать, что нужно делать. Во время инцидента знание того, какие шаги предпринимаются, чтобы его устранить, вселяет уверенность. Благодаря этому люди могут принимать решения о том, что они будут делать в связи с инцидентом.
Мы представляем новую страницу состояния GitLab. Держите пользователей, клиентов и заинтересованные стороны в курсе происходящего во время инцидента. Перенаправляйте информацию об инциденте, например, описание тикетов и выборку комментариев, из частного тикета на общедоступную веб-страницу. Работайте непосредственно с тикетом инцидента, который вы уже используете для фильтрации и устранения неполадок, вместо того, чтобы переключаться между множеством различных инструментов.
Для начала мы нацелились на один конкретный случай использования. Мы разработали страницу статуса, на которой из тикетов специального проекта по управлению инцидентами на приватном инстансе GitLab публикуется информация в публичные страницы статуса. Посетите раздел развития страницы статуса, чтобы ознакомиться с нашими планами по добавлению возможностей и поддержке большего количества вариантов использования.
Документация по странице статуса и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Разработчикам Python нужен удобный механизм создания, обмена и использования пакетов, которые содержат скомпилированный код и другое содержимое, в нужных проектах. PyPI — проект с открытым исходным кодом, поддерживаемый Python Packaging Authority, — является стандартом по определению, созданию, хостингу и использованию пакетов Python.
В GitLab 12.10 мы с гордостью представляем репозитории PyPI, встроенные напрямую в GitLab! Теперь у разработчиков будет более удобный способ публиковать Python-пакеты своих проектов. Интеграция GitLab с PyPI предоставит централизованную локацию для хранения и просмотра этих пакетов в том же месте, где находится их исходный код и конвейеры.
В марте мы объявили, что репозиторий GitLab PyPI и поддержка форматов других менеджеров пакетов будут переведены в открытый исходный код. Вы можете посмотреть, как мы работаем над тем, чтобы сделать эти фичи более доступными в этом эпике.
Документация по репозиторию PyPI и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Defend”
Мы с радостью представляем вам статистику по правилам сетевой безопасности реестра контейнеров! Теперь вы можете видеть данные по общему и заблокированному трафику, что позволит вам проще определять, как настраивать, регулировать и оценивать ваши сетевые правила.
Статистика по правилам реестра контейнеров появится на новой странице Мониторинг угроз (Threat Monitoring) в пункте меню Безопасность и соответствие требованиям (Security & Compliance). По умолчанию эти данные отображаются за 30-дневный период.
Документация по сетевым правилам реестра контейнеров и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Defend”
Для более удобной настройки правил для избежания ложноположительных и ложноотрицательных результатов вы можете глобально переключить ваш файервол веб-приложений в режим Логирование (Logging) или Блокировка (Blocking) на странице Операции -> Kubernetes (Operations -> Kubernetes).
Документация по режимам логирования и блокировки и оригинальный тикет.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
В версии 12.6 GitLab представил модернизированный подход к сбору всей необходимой информации для поддержки соответствия требованиям и аудита в рамках релиза. В 12.10 мы добавили фичу, которая будет создавать временную метку с датой сбора наблюдений Релиза рядом со ссылкой на скачивание хэша наблюдений. Это позволит членам команды с ролью auditor с легкостью сравнивать, как меняются наблюдения по релизу с течением времени вместо того, чтобы писать скрипт для сборки и сравнения каждого фрагмента наблюдений.
Документация по наблюдениям по релизу и оригинальный тикет.
(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”
В GitLab вы можете автоматизировать повторяющиеся рабочие процессы протокола аудита HIPAA. GitLab нативно поможет вам упростить эту работу путем управления тикетами и шаблонами проектов. Этот процесс поможет сопоставить новые тикеты с требованиями протокола аудита HIPAA, а также поможет вашей организации управлять сбором наблюдений аудита и общим состоянием в рамках вашего рабочего процесса в GitLab.
GitLab теперь поддерживает протокол аудита HIPAA с новым шаблоном для версии Enterprise. Для помощи в соблюдении требований GitLab предоставляет новый шаблон для создания проектов со 180 тикетами, которые распределены в соответствии с протоколом аудита HIPAA. Каждый тикет служит как контрольный журнал для каждого протокола HIPAA и может помочь командам оставаться на связи при управлении программами по соблюдению требований HIPAA в GitLab.
Документация по шаблонам Enterprise и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Организациям, нацеленным на соблюдение требований, нужен способ контролировать доступ к их окружению GitLab через SSH. Ключи SSH, как правило, создаются без срока действия. И это является проблемой для организаций с правилами управления доступом и/или данными для доступа, которые требуют определения даты истечения срока действия для всех данных доступа к учетным записям. С этим релизом GitLab поддерживает настройку срока ключей SSH через пользовательский интерфейс GitLab.
Документация по добавлению ключей SSH к вашему аккаунту и оригинальный тикет.
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Руководителям разработки и администраторам GitLab важно знать, как их команды используют GitLab. С этим MVC мы добавили три счетчика на страницу группы: счетчики мерж-реквестов, тикетов и пользователей, добавленных в группу, — все это за последние 90 дней. Эта фича доступна в бета-версии.
Документация по аналитике активности в группе и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Тикеты — это один из основных инструментов для совместной работы в GitLab. По умолчанию события в них отсортированы по дате последних обсуждений и системных заметок от старого к новому. Это очень удобно в таких случаях, как изучение истории данного тикета. Однако это гораздо менее удобно для команд, работающих в режиме разбора и устранения проблем, так как для просмотра последних обновлений им приходится пролистывать до самого конца страницы тикета.
Теперь вы сможете изменить порядок по умолчанию, так чтобы наверху была недавняя активность. Ваши предпочтения по сортировке в тикетах и мерж-реквестах сохраняются отдельно через локальное хранилище и автоматически применяются к каждому тикету и мерж-реквесту, который вы просматриваете.
Документация по сортировке по недавней активности и оригинальный тикет.
(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 и дерева файлов мерж-реквеста. Наслаждайтесь!
Документация по файлам в репозитории и оригинальный тикет.
(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 до того, как очередь репликации закончилась, потеря данных — это ожидаемый побочный эффект автоматического аварийного переключения. Мы уже работаем над строгой согласованностью, чтобы устранить такие сценарии потери данных.
Документация по Praefect и оригинальный эпик.
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Реестр пакетов GitLab позволяет вам хранить огромное количество пакетов разных типов в едином универсальном реестре. До недавнего времени единственным способом более удобно просматривать ваш список пакетов было изменение порядка сортировки. Таким образом было сложно найти определенный пакет, особенно если в вашем реестре много пакетов.
В GitLab 12.10 вы сможете фильтровать по имени (name
), чтобы быстро находить нужные вам пакеты.
Документация по просмотру пакетов и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Все анализаторы сканирования зависимостей теперь поддерживают уровни опасности уязвимостей, что позволяет проще оценивать их риск и приоритет. Ранее уровни опасности поддерживались не для всех языков, из-за чего некоторые уровни опасности обозначались как Unknown
, что осложняло оценку их приоритета.
Документация по сканированию зависимостей и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Одна из важнейших частей мониторинга и наблюдения за производительностью системы и приложений — это оповещения, которые вы получаете, когда что-то идет не так. Без них невозможно соблюдать DevOps и эффективно реагировать на превышение критических порогов в службах. Эти возможности необходимы любой команде разработчиков, и мы хотим, чтобы наше управление оповещениями было доступно любому, кто использует GitLab. Как часть нашего подарка на 2020 год, мы переместили оповещения стадии мониторинга из GitLab Ultimate в GitLab Core. Начиная с GitLab 12.10 все пользователи смогут создавать IT-оповещения в графиках на панели метрик и получать оповещения в GitLab через базовую конечную точку REST.
Документация по оповещениям и оригинальный тикет.
(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 теперь поддерживают настраиваемые временные интервалы. Это позволит вам кроме доступных по умолчанию интервалов визуализировать ваши данные метрик за произвольный интервал, который вы настроите сами.
Документация по языку разметки панели мониторинга и оригинальный тикет.
(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, на которые нет ссылок и оригинальный тикет.
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) “Доступность”
Раньше масштабирование расширенного глобального поиска в GitLab до очень больших экземпляров было сложной задачей из-за слишком большого индекса Elasticsearch. Этот индекс состоял из поисковых данных и конфигураций, которые использовались лишь частично.
Мы заново оценили, какой контент должен быть проиндексирован, и обновили настройки index_options
для нашей конфигурации расширенного глобального поиска. На GitLab.com мы увидели почти 50%-ное снижение нашего продакшн индекса Elasticsearch. Это изменение должно облегчить начало работы с расширенным глобальным поиском и поможет уменьшить накладные расходы при использовании расширенного глобального поиска в 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 требованиям, он должен знать состояние конвейеров для развертываемого кода. Конвейеры могут содержать этапы или задания, определяющие соответствие политике организации. До сих пор администраторы или владельцы групп должны были просматривать каждый проект для проверки каждого конвейера.
Панель мониторинга соответствия требованиям теперь включает в себя самый последний статус конвейера для всех проектов в группе. Администраторы и владельцы групп теперь могут с первого взгляда определить потенциальные проблемы соответствия в утвержденных и смерженных реквестах.
Документация по панели мониторинга соответствия требованиям и оригинальный тикет.
(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. Начиная с этого релиза вы увидите все вики-вклады на страницах проектов, групп и пользователей. Теперь вы можете отслеживать изменения в вики, а редакторы вики будут отмечены за их вклад!
Документация по отслеживанию активности в вики и оригинальный тикет.
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, и включает содержимое, которое можно редактировать в новом, оптимизированном редакторе статического сайта. После развертывания сайта просто нажмите на ссылку «Редактировать эту страницу», отображаемую на каждой странице, и это запустит наш новый редактор, который не показывает посторонний интерфейс, а полностью фокусируется на содержимом страницы. Когда вы закончите, одним щелчком мыши создайте новую ветку и мерж-реквест для ваших изменений.
Документация по редактору статических сайтов и оригинальный эпик.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
При использовании реестра контейнеров GitLab важно иметь межпроектное представление всех ваших образов Docker. До недавнего времени пользовательский интерфейс реестра был доступен только на уровне проекта, что приводило к отсутствию совместной работы и обмена образами Docker между командами.
С релизом 12.10 вы теперь можете просматривать все образы своей группы в приложении GitLab. Теперь вы можете делиться, открывать и управлять всеми своими образами в едином месте.
Документация по управлению реестром контейнеров на уровне группы и оригинальный тикет.
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Как инструмент — «черный ящик», сканирование DAST ничего не знает о базовой архитектуре сайта или приложения. Это может привести к ложным срабатываниям, которые пользователь сразу распознает как ложные. Например сканирование DAST, сообщающее о возможной уязвимости внедрения SQL, когда в архитектуре приложения нет базы данных SQL. Из-за этой проблемы GitLab 12.10 предлагает возможность отключения определенных правил с помощью переменной DAST_EXCLUDE_RULES
. Она принимает список разделенных запятыми идентификаторов правил уязвимости, которые следует исключить из сканирования. С помощью этой переменной вы сможете лучше адаптировать сканирование к целевому приложению, чтобы получать меньше ложных срабатываний.
Документация по настройке DAST и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Эта фича позволяет пользователям легко администрировать свои окружения с помощью пользовательского интерфейса GitLab, а не через API. Управление окружениями через пользовательский интерфейс экономит время и помогает пользователям, предпочитающим проводить свое время в интерфейсе GitLab.
Документация по удалению окружений через интерфейс GitLab и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
При разрешении инцидентов встроенные непосредственно в тикет графики могут сэкономить ваше время, отображая всю важную информацию в едином месте, вместо того, чтобы заставлять вас метаться между разными местами. Однако графики могут и мешать, если вы хотите быстро прочитать текст. Теперь вы можете свернуть и развернуть графики и выбирать между просмотром и их скрытием в тикете.
Документация по встраиванию графиков метрик в шаблоны тикетов и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Мы добавили гистограммы в качестве новой опции визуализации на панели мониторинга, чтобы помочь вам отображать ваши метрики так, как вы хотите.
Документация по гистограммам в Prometheus и оригинальный тикет.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
При просмотре графиков метрик обновление интервала времени теперь также обновляет URL-адрес графика, позволяя вам легко делиться ссылками на определенные временные рамки и добавлять их в закладки.
Документация по интервалам времени и возможности делиться ими и оригинальный тикет.
(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 за эту фичу!
Документация по использованию поиска и оригинальный тикет.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.10 released with Requirements Management and Autoscaling CI on AWS Fargate.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.