Вышел релиз GitLab 12.8 с обозревателем логов, NuGet и панелью управления соответствием требованиям
Новый релиз GitLab 12.8 посвящен подходу «единое место»: для всех ваших логов, пакетов NuGet и контроля за соответствием требованиям. По аналогии с тем, что GitLab — это единое место для всего вашего жизненного цикла DevOps.
Обозреватель логов для быстрой сортировки ошибок
При обработке данных об инциденте или проверке статуса вашего сервиса необходима возможность просматривать логи пода Kubernetes со всего вашего приложения. Ранее это был довольно сложный процесс, так как вы могли видеть только часть логов, не могли вернуться назад или использовать поиск. Это было настолько трудоемко, что использовать логи пода было очень непрактично для содержательного анализа. Поэтому их использовали только в случае простых исправлений и устранения неисправностей.
С новым обозревателем логов вы можете взаимодействовать со всеми вашими логами, собранными в одном месте. Мощные функции, такие как фильтрация, выбор времени и полнотекстовый поиск, позволят быстро получить нужную информацию. Благодаря этой фиче наша категория логов перемещается с minimal на viable! Для того, чтобы подключить эту фичу, установите Elastic stack на вашем кластере Kubernetes с помощью приложения, управляемого GitLab (GitLab Managed app), и ваши логи будут автоматически собираться в одном месте.
Эффективное хранение и совместное использование ресурсов C# и .NET
У Windows — большое, активное и постоянно растущее сообщество разработчиков. В то время, как в GitLab уже было встроенное управление пакетами для C/C++, Java и Node.js, командам, пишущим приложения на C# и .NET, все еще нужно было использовать внешние инструменты для хранения и управления своими файлами. Это означало, что они не могли воспользоваться преимуществами использования одного приложения для всего жизненного цикла DevOps.
С новым релизом GitLab 12.8 разработчики на C# и .NET могут использовать встроенный NuGet-репозиторий, так что теперь у них есть единое место для управления и обмена файлами проекта как приватно, так и в общем доступе. Теперь вы сможете оценить все преимущества того, что ваш исходный код, конвейеры (в русской локализации GitLab «сборочные линии») CI/CD и результирующие пакеты находятся в одном приложении, — и работать быстрее и с меньшими затратами.
Управляйте рисками с помощью панели соответствия требованиям
Мерж-реквесты (в русской локализации GitLab «запросы на слияние») — это элегантный и действенный инструмент управления для ведения учета изменений и их подтверждения. Команды, занимающиеся выпуском релизов, используют их для отслеживания развертываний, а команды, занимающиеся инфраструктурой, используют их для практики GitOps.
Кроме того, отслеживание всей деятельности по мерж-реквестам может быть критически важным для организаций с конкретными корпоративными правилами, регулирующими их деятельность для соблюдения требований стандартов, таких как SOC 2, ISO 27001, GDPR, SOX, HIPAA и PCI-DSS.
Некоторые примеры стратегий управления:
- У каждого мерж-реквеста есть связанный тикет с подробной информацией об изменениях
- Все мерж-реквесты рассматриваются и подтверждаются не авторами
- Все мерж-реквесты проходят тестирование на качество и безопасность
- Любые исключения из требований требуют отдельного подтверждения
Ранее у пользователей GitLab не было необходимых инструментов для эффективного управления изменениями инстанса GitLab и соблюдения требований в нем. Активность на уровне проекта была ограничена конкретным проектом, и не было простого способа просмотреть эту информацию по всем проектам на групповом уровне. Такое отсутствие контроля и прозрачности создавало потенциальные риски, снижая возможности пользователей по управлению соответствием требованиям в GitLab.
Мы разработали концепцию надежной системы управления соответствием требованиям для GitLab. В качестве первого шага мы добавили панель управления соответствием требованиям, которая показывает последние мерж-реквесты для каждого проекта в группе. С ее первой версией вы можете управлять аудитом изменений вашего кода для релизов и GitOps из одного места. Организациям, нацеленным на соблюдение требований, эта панель предоставляет возможность быстро понять, какие проекты подвержену большему риску и, следовательно, заслуживают дополнительного внимания. В наших следующих релизах вас ждет больше возможностей и улучшений.
И это еще не все!
Это — лишь небольшая выборка из всех обновлений релиза 12.8. Посмотрите также вот эти классные обновления: просмотр заблокированных тикетов, правила истечения срока действия образов Docker и одноуровневые эпики (в русской локализации GitLab «цели»), теперь доступные в Premium!
Приглашаем на наши встречи и просим заполнить опрос по релизу (на английском).
MVP этого месяца — Roger Meier
Роджер добавил поддержку S/MIME подписей коммитов, которая позволяет вам с помощью стандарта X.509 подтвердить, что вы являетесь автором коммита. Эта фича пригодится для конфиденциальных проектов и в регулируемых отраслях. Товарищ Роджера по команде, Henning Schild, отправил это изменение в Git, а Роджер добавил его в GitLab.
Посмотрите нашу документацию по подписанию коммитов с X.509 и начните использовать эту фичу уже сегодня. Спасибо Роджеру за этот вклад!
Основные фичи релиза GitLab 12.8
Агрегирование логов
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
В современном облачном мире, где краткосрочные сервисы и логи распределены по нескольким подам и сервисам, критически важно агрегировать логи для их своевременного отслеживания. Релиз GitLab 12.8 представляет обозреватель логов с использованием Elastic stack.
После присоединения кластера Kubernetes вы можете установить Elastic stack, который содержит инстанс Elasticsearch с Filebeat, легковесным поставщиком логов. После этого GitLab будет автоматически собирать все логи ваших приложений и удобно отображать их в пользовательском интерфейсе.
Таким образом, вы сможете просматривать агрегированные логи Kubernetes по разным сервисам и всей инфраструктуре, возвращаться назад во времени, осуществлять бесконечную прокрутку и поиск по логам ваших приложений.
Это может пригодиться, если вы обрабатываете инцидент в приложении или проверяете статус своего сервиса, или если вам необходимо просмотреть логи приложения и выполнить полнотекстовый поиск. Также эта фича поможет понять, что влияет на производительность вашего приложения, и позволит устранять любые проблемы по мере их возникновения.
Документация по поиску по логам пода и оригинальный эпик.
Собирайте, публикуйте и делитесь пакетами с помощью репозитория NuGet (.NET) GitLab
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Для любой организации, поставляющей программное обеспечение, крайне важно дать командам простой и безопасный способ управления зависимостями. Менеджеры пакетов, такие как NuGet for C# .NET, предоставляют стандартизированный способ совместного использования и управления версиями этих библиотек среди различных проектов.
В GitLab 12.8 мы с гордостью представляем репозитории NuGet, встроенные непосредственно в GitLab. Теперь у разработчиков есть более простой способ публиковать NuGet-пакеты своих проектов. Все, что вам нужно сделать, это указать удаленный сервер NuGet в реестре пакетов GitLab, и вы сможете начать загрузку, установку и удаление пакетов.
Документация по NuGet-репозиторию и оригинальный тикет.
Панель управления соответствием требованиям
(ULTIMATE, GOLD) Стадия цикла DevOps: “Manage”
Организациям, которые требуют строгого соблюдения требований, нужна прозрачность. Но по мере того, как в GitLab добавляется все больше групп, проектов и пользователей, добиться прозрачности становится все сложнее, и это может затруднить должное управление рисками и соответствием требованиям.
В GitLab 12.8 мы добавили специальную панель управления на уровне группы, в которой владельцы групп могут ознакомиться с информацией о соответствии требованиям. Первая итерация этой панели собирает все недавние мерж-реквесты, подтвержденные и принятые, из каждого проекта в группе. Теперь владельцы групп будут видеть всю активность по мерж-реквестам в одном месте и смогут при необходимости принять меры.
Документация по панели управления соответствием требованиям и оригинальный тикет.
Правила для сетевой безопасности контейнеров
(ULTIMATE, GOLD) Стадия цикла DevOps: “Defend”
Мы рады представить первоначальную поддержку сетевой безопасности контейнеров, которая поможет предотвратить атаки типа Lateral Movement. Теперь вы можете настроить сетевые правила (NetworkPolicy) в кластерах Kubernetes, управляемых GitLab, чтобы ограничить взаимодействие между подами Kubernetes.
Эти правила могут контролировать взаимодействие между подами и интернетом, а также предотвращать несанкционированное взаимодействие подов с другими подами в том же кластере Kubernetes. В кластере с несколькими приложениями эта фича также позволяет сегментировать сеть между различными приложениями.
Документация по настройке сетевой безопасности с помощью Cilium и оригинальный тикет.
Одноуровневые эпики теперь доступны в Premium
(PREMIUM, SILVER) Стадия цикла DevOps: “Plan”
Для поддержки наших пользователей, которые планируют большие объемы связанных работ и управляют ими на протяжении нескольких майлстоунов (в русской локализации GitLab «этапы»), спринтов и итераций, мы представляем одноуровневые эпики для владельцев планов Premium и Silver!
Создайте эпик, создавайте и добавляйте связанные с ними тикеты, устанавливайте даты начала и окончания работ, — и систематизируйте все это с помощью перетаскивания элементов по дереву эпика.
Документация по эпикам и оригинальный тикет.
Блокировка тикетов
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Четкое определение зависимостей тикетов стало еще проще. Теперь вы можете отмечать тикеты как блокирующие или заблокированные другими тикетами. Благодаря этому увидеть тикеты, которые могут нуждаться в дополнительном внимании (заблокированные), или тикеты, которые принесут значительный результат (блокирующие), теперь будет легче, чем когда-либо. Эффективность командной работы также повысится, поскольку теперь можно наглядно представить взаимоотношения внутри команды.
Документация по связанным тикетам и оригинальный тикет.
Ограничения по тикетам «в работе» на досках задач
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Чем больше тикетов находится в работе на данном этапе, тем больше времени требуется для завершения каждого из них. Ограничения по тикетам «в работе» (Work In Progress, WIP) обычно используются командами, практикующими Kanban, и являются проверенным методом повышения скорости выполнения работ.
Начиная с 12.8 вы можете устанавливать ограничения по WIP-тикетам в списке на доске задач (в русской локализации GitLab «доска обсуждений»). Если вы превысите лимит, фоновый цвет списка изменится на красный.
Документация по доскам задач, оригинальные тикет и мерж-реквест.
Заблокированные тикеты теперь визуально отличаются на досках задач
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
Теперь вы сможете легко определить, какие тикеты сейчас заблокированы другими и требуют вашего внимания, просто взглянув на доску задач — вы сразу поймете, что замедляет вашу работу. Закройте блокирующие тикеты, и ваша команда снова сможет работать эффективно.
Документация по заблокированным тикетам и оригинальный тикет.
Автоматическая остановка окружения после заданного периода
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Теперь вы можете установить срок для автоматической остановки окружения после определенного периода простоя. Такая настройка поможет избежать лишних трат на окружения с коротким временем жизни, например, используемых для приложений для ревью. Настроить этот срок можно в .gitlab-ci.yml, добавив строчку типа auto_stop_in: 1 week, и его можно вручную переопределить из пользовательского интерфейса GitLab. Пользователи также могут отключить функцию автоматической остановки, закрепив конкретное окружение через пользовательский интерфейс и поддерживая его запущенным вне зависимости от настроек.
Теперь вы не будете тратить ресурсы инфраструктуры впустую на поддержку множества устаревших окружений. Вы также выиграете во времени на разработку, которое в противном случае было бы потрачено на остановки окружений вручную.
Документация по автоматической остановке окружения и оригинальный тикет.
Панель управления безопасностью для инстанса
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
В релизе 12.8 стал доступен просмотр уязвимостей безопасности на уровне инстанса. На этой панели управления вы увидите обзор возможных проблем с безопасностью во всех группах и проектах вашего инстанса.
В дополнение к просмотру списка уязвимостей в ваших проектах и динамики уязвимостей с течением времени, на панели вы увидите проекты во всех группах, отсортированные по буквенным оценкам отчета по безопасности для быстрого принятия решения о том, какой проект сейчас нуждается в наибольшем внимании.
Документация по панели управления безопасностью и оригинальный тикет.
Автоматические сканирования на доступность в приложениях для ревью
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Все больше разработчиков программного обеспечения обеспокоены доступностью веб-страниц и приложений. К сожалению, в процессе разработки программного обеспечения тестирование на доступность часто бывает второстепенным. Как правило, это ручной и непоследовательный процесс, если он вообще проводится. Командам разработчиков часто не хватает от менеджеров по продуктам или дизайнеров четких требований, описывающих стандарты доступности, которым необходимо следовать при создании приложения.
Начиная с GitLab 12.8 в приложениях для ревью появилась возможность автоматического сканирования и получения отчета о проблемах с доступностью. Это позволит сэкономить время разработки, быстрее получая обратную связь по вопросам доступности, что окажет значительное влияние на то, насколько доступно будет это приложение для всех пользователей. В качестве первого шага вы можете загрузить отчет по каждому мерж-реквесту.
Мы рассматриваем эту фичу как надежный фундамент для дальнейшего развития в области тестирования доступности. Мы с нетерпением ждем ваших отзывов о нашем подходе к тестированию на доступность.
Документация по тестированию доступности и оригинальный тикет.
Другие улучшения в GitLab 12.8
Автоматическое подтягивание артефактов для межпроектных заданий
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Теперь можно указывать, что задание в проекте зависит от последнего артефакта, произведенного заданием на другом конвейере. Это значительно упростит настройку межпроектных конвейеров, которые имеют зависимости артефактов друг от друга.
В качестве примера можно привести конвейер, который собирает исполняемый двоичный файл. До этого обновления вам приходилось каждый раз пересобирать все библиотеки, от которых зависел этот файл, даже если сама библиотека не менялась. Это была пустая трата времени и вычислительных мощностей, а обходные пути требовали использования хрупкой комбинации ключей API, cURL и защищенных переменных. Теперь же, указав artifacts: true в needs: вашего задания, вы сможете подтянуть артефакт, сгенерированный конвейером библиотек, и использовать его в окончательном конвейере без необходимости пересборки.
Документация по использованию артефактов между конвейерами и оригинальный тикет.
Правила подтверждения мерж-реквестов для защищенных веток
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Код-ревью — основополагающая практика любого успешного проекта, и правила подтверждения мерж-реквестов помогут убедиться, что каждое изменение проверят нужные люди. Это особенно важно при реализации непрерывной поставки (continuous delivery) или при работе над проектами с повышенным риском. Раньше добавление более строгих правил подтверждения для защиты ветки по умолчанию привело бы к одинаковым требованиям для каждой ветки. Из-за этого все мерж-реквесты должны были соответствовать одним и тем же правилам, будь то принятие исправления из ветки master в релизную, или же между двумя выделенными ветками.
GitLab 12.8 решает эту проблему: правила подтверждения мерж-реквестов, установленные на уровне проекта, могут запрашиваться выборочно, исходя из целевой ветки мерж-реквеста. Это позволяет применять эти правила именно тогда, когда они необходимы, и даже применять разные правила к разным веткам, например, к стабильным релизным веткам.
Документация по правилам подтверждения мерж-реквестов и оригинальный тикет.
Улучшенная производительность алгоритма сборщика мусора для S3 в реестре контейнеров GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Для организаций, создающих множество образов для множества разных проектов, важно иметь возможность удалять старые ненужные образы и теги. Сборщик мусора реестра контейнеров GitLab работает медленно и неэффективно использует ресурсы. Поэтому для инстансов с большими реестрами сложно использовать сборщик мусора, что приводит к дополнительным расходам на хранение.
В GitLab 12.8 мы с радостью объявляем о значительном улучшении в производительности сборщика мусора для инстансов, использующих S3 для хранения. Эти улучшения касаются стадий mark и sweep. При тестировании на 15 тысячах образов время выполнения стадии mark снизилось с 25 минут до 90 секунд, а время выполнения стадии sweep снизилось с 20 минут до 3 секунд! Вы можете узнать больше о тестах производительности и оптимизации выполнения бенчмарка в соответствующем мерж-реквесте.
Документация по реестру контейнеров и оригинальный тикет.
Удаление поврежденных манифестов Docker при сборке мусора
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
При запуске сборщика мусора для удаления старых неиспользуемых образов пользователи часто сталкивались с проблемой, при которой процесс завершался неудачно из-за поврежденных манифестов Docker. Для разрешения этой проблемы администраторам приходилось вручную удалять поврежденные файлы из хранилища объектов, что было медленно и рискованно.
Мы рады сообщить, что начиная с релиза 12.8 любые поврежденные манифесты будут удаляться в процессе сборки мусора. Если в процессе сборки мусора будет найден файл с некорректной ссылкой (нулевой размер или невалидная контрольная сумма), то вместо остановки процесса сборщик выдаст предупреждающее сообщение и проигнорирует файл. Все blob, связанные с такими файлами, будут удалены на стадии sweep, если эти blob не связаны с другим файлом с валидной ссылкой. Это обновление делает процесс сборки мусора более надежным и эффективным.
Документация по сборщику мусора реестра контейнеров и оригинальный тикет.
Верификация подписи коммитов через S/MIME
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
У каждого коммита в репозитории Git есть автор, однако подлинность автора невозможно проверить средствами Git, а это означает, что легко можно создать коммит, подписавшись чужим именем. Подпись коммита позволит вам доказать, что именно вы являетесь его автором. Это важно для проектов с высокими требованиями к безопасности и в некоторых коммерческих окружениях.
В Git 2.19 поддержка подписи и верификации с помощью OpenGPG распространилась на использование S/MIME с сертификатами X.509, так как крупным организациям намного проще управлять этими сертификатами.
GitLab теперь тоже поддерживает верификацию подписи коммитов через S/MIME благодаря Roger Meier из Siemens! Также мы благодарны Henning Schild, тоже из Siemens, за разработку этой фичи для Git!
Документация по подписям коммитов сертификатами X.509 и оригинальный тикет.
Отключение самоподтверждения мерж-реквестов на уровне инстанса
(PREMIUM, ULTIMATE) Стадия цикла DevOps: “Manage”
Мы добавили новые настройки инстансов для предотвращения нежелательных изменений настроек подтверждений мерж-реквестов. Для этого мы перенесли некоторые настройки из настроек проекта в область настроек администратора. Это позволит администраторам лучше контролировать развертывания и разделять обязанности при развертывании кода.
При включении этих настроек на уровне инстанса в инстансах с самоуправлением они будут автоматически применены для всех проектов, и только администраторы смогут изменять их для конкретных проектов. Благодаря этим настройкам, только подтвержденные развертывания попадут в продакшн, и это приведет ваши проекты GitLab в надлежащее состояние.
Документация по подтверждению мерж-реквестов и оригинальный тикет.
Метаданные GitLab теперь доступны через пользовательский интерфейс реестра пакетов
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
В ходе недавнего опроса пользователей мы узнали, что пользователи переходят на страницу пользовательского интерфейса реестра пакетов, чтобы узнать, какую версию пакета им стоит использовать, или чтобы убедиться, что конвейер правильно собрал пакет. Однако, из-за того, что мы не отображали в этом интерфейсе никакой информации о том, как происходит сборка пакета, пользователям приходилось переключаться между несколькими различными областями приложения.
Мы рады объявить, что в GitLab 12.8 пакеты, собранные при помощи конвейеров GitLab теперь будут включать переменные pipeline_id, branch и commit в на странице реестра пакетов. Это поможет пользователям понять, как был собран данный пакет, и упростит устранение неполадок, если что-то пойдет не так.
Документация по пакетам и оригинальный тикет.
Управление доступом к защищенным окружениям через API
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Release”
До сих пор для настройки уровней доступа для защищенных окружений пользователям приходилось обновлять разрешения ролей developer и maintainer через пользовательский интерфейс вместо интерфейса командной строки. Это было неэффективно для пользователей, которые работают через командную строку, и которым нужно поддерживать тот же уровень доступа для нескольких групп. Начиная с этого релиза, maintainers смогут экономить время, разрешая или запрещая доступ к защищенным окружениям через API, а не путем обновления разрешений через пользовательский интерфейс настроек.
Документация по защищенным окружениям и оригинальный тикет.
Включение приложений для ревью вставкой фрагмента кода
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Мы хотим сделать приложения для ревью простыми в установке, даже если у вас уже есть рабочий файл .gitlab-ci.yml. Мы добавили на страницу окружения новую кнопку Включить приложения для ревью (Enable Review Apps). Если вы используете Kubernetes и хотите включить приложения для ревью, то нажатие на кнопку покажет вам фрагмент кода YAML, который нужно добавить в ваш файл .gitlab-ci.yml.
Документация по включению приложений для ревью и оригинальный тикет.
Задания без предшественников в конвейерах с архитектурой направленного ациклического графа
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Чтобы показать GitLab, что для данного задания нет предшественников и что его всегда можно запускать немедленно, независимо от того, на какой оно стадии, можно задать пустой массив needs:. Таким образом вы можете задавать более гибкие отношения для конвейеров с архитектурой направленного ациклического графа, что позволит ускорить их выполнение и сделать их более эффективными.
Документация по переменной needs: и оригинальный тикет.
Улучшенный баннер с информацией по лицензии для Geo
(CORE, STARTER) “Доступность”
Geo доступен только для тарифов Premium и Ultimate. Ранее, если вы пытались включить Geo через интерфейс администратора при использовании лицензии Starter или Core, мы просто говорили вам, что ваша лицензия недействительна — не очень полезная информация. Теперь мы показываем более информативное сообщение, в котором говорится, какой лицензией вы пользуетесь, какая нужна для использования Geo, и в котором есть ссылка на страницу управления лицензиями.
Мы надеемся, что вы дадите Geo шанс!
Документация по Geo и оригинальный тикет.
Новые события аудита
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Manage”
Мы продолжаем добавлять события аудита, чтобы улучшить отслеживание активности в инстансах с самоуправлением и группах на GitLab.com. В этом релизе мы добавили действия администратора для создания, блокировки и удаления пользователей и включения изменений имен пользователей в логи инстансов с самоуправлением.
Эти новые события аудита помогут организациям, нацеленным на соблюдение требований, обеспечивать разделение обязанностей, управление доступом и неоспоримость действий (nonrepudiation).
Документация по событиям аудита и оригинальный эпик.
Масштабирование графиков метрик
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Ось Y на графике метрик раньше всегда начиналась с нуля. Из-за этого пользователям было сложно отслеживать небольшие изменения на графике. Начиная с версии 12.8 значения шкалы Y будут автоматически масштабироваться согласно отображаемым данным.
Документация по графикам Prometheus и оригинальный тикет.
Поиск окружений на панели метрик
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Поиск нужного окружения может сильно затянуться, если у вас их много. Теперь вы сможете быстро находить окружения, которые вы хотите видеть на панели метрик, в новой строке поиска в выпадающем меню.
Документация по поиску окружений в выпадающем меню и оригинальный тикет.
Столбчатые диаграммы для панели метрик
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
При визуализации метрик пользователи зачастую хотят использовать разные типы графиков для разных метрик. Чтобы помочь им в этом, мы добавили столбчатые диаграммы в качестве нового способа визуализации на панели мониторинга. Визуализируйте ваши данные так, как вам больше нравится!
Документация по столбчатым диаграммам и оригинальный тикет.
Решение проблем со сборщиком мусора Docker для реестров контейнеров, использующих DigitalOcean S3
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Существует известная проблема при использовании Docker, при которой Ceph-хранилища для всех запросов с абсолютным URI влияют на работу сборщика мусора Docker. Так как DigitalOcean использует Ceph, он не дает пользователям запускать сборщик мусора, если они используют DigitalOcean для хранения. Это приводит к увеличению расходов на хранение.
В GitLab 12.8 мы решили эту проблему, обновив драйвер для Ceph, чтобы он поддерживал последнюю версию API. Это позволит всем организациям, использующим DigitalOcean в качестве хранилища для реестра контейнеров GitLab, запускать сборщик мусора, снижая таким образом расходы на хранение.
Документация по сборщику мусора реестра контейнеров и оригинальный тикет.
Изменение имени отправителя писем из службы поддержки
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Plan”
По умолчанию письма, отправленные из вашей службы поддержки (Service Desk) на GitLab.com приходят от отправителя GitLab Support Bot. Во многих случаях авторы тикета не знают, что они переписываются с GitLab, из-за чего возникает путаница.
Теперь вы можете изменять имя отправителя писем из службы поддержки. Это позволит вам задать узнаваемое имя, соответствующее вашему бренду, чтобы ваши пользователи знали, с кем они переписываются.
Документация по изменению имени отправителя писем из службы поддержки и оригинальный тикет.
Протокол Git v2
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Мы снова добавили поддержку протокола Git v2 через HTTP. Ранее мы объявляли о его поддержке в GitLab 11.4, однако были вынуждены отказаться от нее из-за проблемы с безопасностью в версиях Git до Git 2.21.
Разработчики проверяют обновления в репозиториях (git fetch) по несколько раз в день, чтобы проверить, не отстает ли их текущая локальная ветка от удаленной. Протокол Git v2 — это крупное обновление коммуникационного протокола Git, который определяет, как команды clone, fetch и push передаются между клиентом (вашим компьютером) и сервером (GitLab). Новый коммуникационный протокол улучшает производительность команд fetch и дает возможность для дальнейшего улучшения протокола.
Ранее все ответы на команды fetch включали в себя список всех ссылок (refs) в репозитории. Например, при скачивании обновлений для одной ветки (например, git fetch origin master) вы бы также получили полный список всех ссылок. Для больших проектов это может включать более 100 000 ссылок и десятки мегабайтов данных.
Протокол Git v2 поддерживается с версии Git 2.18.0 и не включен по умолчанию. Для подключения протокола выполните команду git config --global protocol.version 2. Протокол Git v2 через SSH пока не доступен. Следите за этим тикетом, чтобы получать обновления.
Документация по протоколу Git и оригинальный тикет.
Больше шаблонов CI/CD для приложений Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Установка приложений Kubernetes при помощи GitLab CI/CD — это отличный способ настраивать приложения под себя перед установкой.
В GitLab 12.8 доступны новые шаблоны для установки JupyterHub и Elastic Stack через GitLab CI/CD. Установка приложений через GitLab CI/CD также предоставляет контроль версий и управление доступом к установленным чартам.
Документация по установке через GitLab CI/CD (альфа) и оригинальный тикет.
Умное переиспользование пакфайлов Git
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
В GitLab 12.8 мы добавляем в Omnibus GitLab версию Git 2.24 с патчами для улучшения повторного использования пакфайлов Git. se between the cost to serve a clone or a fetch, and the quality of the resulting packfile.
Когда клиент копирует или скачивает данные, для сервера эффективным решением будет как можно больше переиспользовать уже существующие пакфайлы. Улучшения заключаются в использовании нового, более умного алгоритма для повторного использования пакфайлов, который находит лучший компромисс между стоимостью выполнения клонирования или скачивания и качеством получаемого пакфайла.
Спасибо Peff и GitHub за то, что поделились этим улучшением, и спасибо Jonathan Tan (Google) за помощь в ревью! Мы надеемся, что патчи дойдут до Git 2.26.
Документация по патчам для повторного использования пакфайлов и оригинальный тикет.
Использование ядра delta islands Git
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
В зависимости от структуры пакфайла на диске, клонирование репозитория Git может очень сильно нагружать процессор и память, если Git приходится собирать и сжимать пакфайл на лету. Экстремальная нагрузка на процессор и память может произойти при одновременном многократном клонировании крупного репозитория, например, при выполнении конвейера CI с параллельными процессами. Однако, если вы запустите повторное использование пакфайла, то вместо того, чтобы создавать его на лету, Git загрузит пакфайл напрямую с диска, что позволит избавиться от большей части нагрузки на процессор и память.
В GitLab 12.8 при перепаковке репозиториев создается ядро delta island, которое содержит все достижимые ветки и теги, так что при клонировании репозитория Git запускается повторное использование пакфайла. Для активных репозиториев GitLab создает репаки автоматически, однако их создание также можно запускать вручную, кликнув Run Housekeeping в общих настройках проекта. При использовании «тонких» клонов для CI повторное использование пакфайла не будет запускаться.
Документация по delta islands и оригинальный тикет.
Документация по использованию предыдущих версий Knative
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Knative приближается к версии 1.0, однако многим пользователям GitLab пока приходится собирать более ранние версии Knative, так как процесс обновления Knative пока работает не безупречно. При этом возникает проблема, так как новые версии gitlabktl поддерживают только определенную версию Knative из-за изменений в API. Мы решили не добавлять поддержку старых версий, так как GitLab Serverless является альфа-фичей. По мере того, как мы добавляли обновления, каждая версия gitlabktl поддерживала только определенную версию Knative. Такая стратегия упрощает разработку и позволяет нам быстро выполнять итерации, однако она усложнила обновление GitLab, так как нам пришлось также добавлять обновления для Knative.
Эту проблему можно решить, используя закрепленную версию gitlabktl. Хотя такая возможность существовала всегда, додуматься до этого было непросто. Теперь мы добавили в нашу документацию четкий набор инструкций, чтобы упростить поиск и применение этого решения.
Документация по использованию предыдущих версий gitlabktl и оригинальный тикет.
Быстро обновляемая база данных уязвимостей
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Мы постоянно обновляем нашу базу данных уязвимостей с учетом последних уязвимостей. Это гарантирует, что сканеры GitLab всегда ищут все уязвимости (в том числе и последние), защищая вас и ваши приложения.
В феврале 2020 года мы добавляли известные уязвимости в нашу базу данных в среднем за 2,2 дня после их объявления. Вы можете увидеть текущий статус наших обновлений уязвимостей в справочнике.
Документация по обновлениям базы данных уязвимостей и оригинальный тикет.
Исправление ошибок
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Некоторые из примечательных исправлений в GitLab 12.8:
Все исправления ошибок в GitLab 12.8.
Темная тема подсветки синтаксиса для Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
GitLab давно поддерживает альтернативные темы подсветки синтаксиса при просмотре файлов в репозитории или различий во время ревью кода. Однако наш редактор кода до сих пор не поддерживал темы подсветки синтаксиса, несмотря на то, что это наиболее востребованная фича для Web IDE.
Web IDE теперь поддерживает выбор темной темы подсветки синтаксиса при редактировании кода. Мы начали с этой темы, поскольку она самая популярная, не считая стандартной, но мы продолжим расширять возможности настройки подсветки синтаксиса в Web IDE. Мы также будем работать над расширением темной темы на остальные части Web IDE, включая дерево файлов и боковые панели.
Документация по темам подсветки синтаксиса и оригинальный тикет.
Импорт и экспорт проектов теперь быстрее и надежнее
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) “Доступность”
В GitLab 12.8 значительно улучшились импорт и экспорт проектов, что приведет к ускорению выполнения и повышению надежности.
Экспорт проектов теперь выполняется в четыре раза быстрее, при этом объем используемой памяти сокращается на 80%. Ранее экспорт крупных проектов мог завершиться неудачей из-за превышения ограничений по памяти. Теперь, когда памяти требуется меньше, у этих заданий намного больше шансов на успех.
Импорт проектов происходит примерно на 50% быстрее, благодаря значительному сокращению вызовов базы данных. В будущем мы планируем сократить объем памяти, необходимый для импорта, перейдя на формат JSON с символом новой строки в качестве разделителя.
Документация по импорту и экспорту и оригинальный тикет.
Использование правил для удаления образов Docker
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Вы создаете много образов Docker в рамках своих конвейеров, однако многие из этих образов нужны только в течение короткого времени. До сих пор вам приходилось удалять образы через API реестра контейнеров или через пользовательский интерфейс. Оба варианта требуют усилий. Разве не было бы замечательно определить такие правила, чтобы эти нежелательные теги удалялись автоматически?
В 12.8 мы рады представить правила истечения срока действия тегов Docker для всех новых проектов. Эта новая функция позволяет идентифицировать тег по имени, выбирать, сколько версий тега сохранить, и определять, когда его следует удалить. Например, вы можете установить правило, которое будет удалять все имена тегов, которые соответствуют регулярному выражению, например, Git SHA, всегда сохранять как минимум пять образов и удалять любой образ старше 30 дней.
Документация по политике истечения срока действия для реестра контейнеров и оригинальный тикет.
Сбор материалов релиза на дату окончания релиза
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Release”
Когда пользователи впервые создают запись в разделе «Релизы», для подтверждения в случае аудита берется снимок метаданных. Начиная с 12.8 мы автоматически делаем дополнительный снимок материалов релиза на дату окончания релиза. Когда есть второй снимок, можно сравнить начальное состояние релиза с его конечным состоянием. Так аудиторские команды будут лучше понимать, что поменялось между этими двумя моментами времени.
Документация по снимкам материалов релиза и оригинальный тикет.
Geo движется к автоматизированной платформе для разработчиков
(PREMIUM, ULTIMATE) “Доступность”
Geo помогает работе распределенных команд благодаря репликации данных на локальные ноды Geo, а также используется для аварийного восстановления. Некоторые функции GitLab пока не поддерживаются Geo. Мы бы хотели, чтобы все будущие функции поставлялись с поддержкой Geo из коробки. Чтобы достичь этого, мы движемся к платформе разработки, которая облегчит разработчикам из сообщества GitLab предоставление новых типов данных, которые необходимо реплицировать и проверять.
Это важно, поскольку стандартизирует технические процессы, используемые в Geo для расширения Geo на другие части GitLab, и предоставит сообществу разработчиков GitLab прочную техническую базу для внесения будущих фич и улучшений в Geo. Фактически, будущие разработки будут быстрее и эффективнее.
В этом релизе мы собрали для файлов пакетов первую итерацию, которая устанавливает технические основы этой работы. В следующей итерации мы добавим поддержку репликации и проверки файла пакета.
Документация по Geo, оригинальный тикет и эпик.
Хранилище для учетных записей, управляемых группой
(ULTIMATE, GOLD) Стадия цикла DevOps: “Manage”
Управление доступом к вашим группам на GitLab.com требует просмотра учетных данных, которые люди используют для действий в этих группах.
В GitLab 12.8 мы расширили хранилище учетных данных с самоуправляемых экземпляров до GitLab.com. Теперь владельцы учетных записей, управляемых группами, могут просматривать учетные данные SSH и токены личного доступа, существующие в их группах. Это хранилище показывает пользователя, тип учетных данных и дату истечения срока действия, чтобы вы могли принимать обоснованные решения о доступе и ротации.
Документация по инвентаризации для учетных записей, управляемых группой и оригинальный тикет.
Реестр NPM GitLab поддерживает теги для распространения
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Пользователи хотели бы использовать метаданные пакета, чтобы убедиться, что их пакет NPM был загружен, или для поиска правильной версии пакета. Теги NPM можно использовать для предоставления псевдонима вместо номеров версий, что упрощает поиск пакетов. Например, проект может выбрать несколько направлений разработки и использовать разные теги для них — stable,beta, dev или canary.
Мы рады сообщить, что с GitLab 12.8 мы поддерживаем теги распространения NPM в нашем реестре NPM. Теперь вы можете добавлять, удалять и перечислять теги, связанные с любым пакетом, размещенным в реестре, что позволит быстрее и проще находить и обнаруживать пакеты.
Документация по тегам распространения NPM и оригинальный тикет.
Поддержка модулей Go в сканировании зависимостей
(ULTIMATE, GOLD) Стадия цикла DevOps: “Secure”
Мы рады добавить модули Go в список поддерживаемых языков при сканировании зависимостей.
Хотя этот сканер уже действующий, эта фича пока в альфа-версии, поскольку база данных содержит определения уязвимостей модуля Go только начиная с 2019 года и позже. В этом эпике мы кропотливо собираем любые отзывы о желаемом возрасте и типах поддержки Go в дополнение к любым проблемам, с которыми вы сталкиваетесь. Это поможет нам вывести поддержку этого языка из альфы.
Документация по поддерживаемым языкам при сканировании зависимостей и оригинальный тикет.
В новом синтаксисе правил появилось действие allow-failure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
В качестве расширения нашего нового синтаксиса правил теперь можно определить правила конвейера, которые допускают возможность невыполнения. Это дает пользователям больше гибкости при настройке поведения их заданий и облегчает перенос дополнительных проектов в наш новый, более понятный для человека синтаксис.
Документация по правилам, разрешающим неуспех и оригинальный тикет.
Увеличенная длина журнала в сообщениях об ошибках конвейера
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”
Длина журнала в сообщениях об ошибках конвейера увеличилась с 10 до 30 строк, что облегчит просмотр большей части трассировки и повысит вероятность того, что все сообщение об ошибке поместится в электронное письмо.
Спасибо Philipp Hasper за эту фичу!
Документация по уведомлениям и оригинальный тикет.
PostgreSQL 11 теперь доступен в Omnibus GitLab
(CORE, STARTER, PREMIUM, ULTIMATE) “Доступность”
Пакет Omnibus GitLab теперь включает в себя PostgreSQL 11. Релиз PostgreSQL 11 включает в себя усовершенствования в разметке разделов и другие улучшения производительности, которые мы будем использовать в GitLab 13.x для повышения его общей скорости и скорости отклика. PostgreSQL 11 был полностью протестирован с Omnibus GitLab для новых установок и обновлений, включая конфигурации, требующие высокой доступности (HA). Сейчас идет тестирование с Geo.
Обновления до PostgreSQL 11 по умолчанию выключены для GitLab 12.8. Инструкции по обновлению смотрите в примечаниях к обновлению. Новые установки и автоматические обновления с 9.6 по-прежнему по умолчанию будут использовать PostgreSQL 10. PostgreSQL 11 будет доступен из коробки в GitLab 12.10 и станет минимально необходимой версией PostgreSQL в GitLab 13.0. Более подробную информацию о дорожной карте PostgreSQL 11 в GitLab смотрите в эпике о добавлении поддержки PostgreSQL 11.
Мы рекомендуем администраторам инстансов, не использующих Geo, перейти на PostgreSQL 11 при первой же возможности, чтобы воспользоваться улучшением производительности и подготовиться к удалению PostgreSQL 9.6 и 10.x в GitLab 13.0.
Документация по изменениям в Omnibus GitLab 12 и оригинальный тикет.
Автоматическое закрытие тикета при устранении связанной ошибки Sentry
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Управлять ошибками в вашем приложении и так достаточно сложно, даже когда не надо помнить о необходимости закрыть тикет в GitLab после исправления ошибки. Тикеты в GitLab теперь закрываются автоматически после устранения связанной ошибки Sentry. Это избавляет вас от дополнительной ручной работы и предотвращает путаницу, когда тикеты остаются активными.
Документация по исправлению ошибок и оригинальный тикет.
Дублирование панели мониторинга вместе с пользовательскими метриками
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”
Ранее дублирование панелей мониторинга включало только стандартные метрики. Благодаря этому новому усовершенствованию в 12.8 пользовательские метрики включаются при клонировании панели мониторинга от GitLab, в которой были пользовательские метрики и метрики по умолчанию.
Документация по клонированию панелей мониторинга и оригинальный тикет.
Проект самомониторинга GitLab
(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: “Monitor”
Администраторы GitLab теперь могут получать информацию о состоянии своих инстансов GitLab, используя новый базовый проект, который будет добавлен в группу «Администраторы инстансов GitLab» (“GitLab Instance Administrators”). Он создан для визуализации и настройки ключевых метрик для мониторинга вашего экземпляра GitLab.
Документация по проекту самомониторинга GitLab и Оригинальный тикет.
Переход от диаграммы метрик к логам
(ULTIMATE, GOLD) Стадия цикла DevOps: “Monitor”
При работе с инцидентом важно просматривать и журналы, и метрики. Теперь при просмотре диаграммы метрик вы можете переходить непосредственно к просмотру логов, сохраняя контекст и не выходя из консоли GitLab.
Документация по elastic-stack и оригинальный тикет.
Улучшена производительность API удаления для фронтенда реестра контейнеров
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”
Пользовательский интерфейс реестра контейнеров GitLab позволяет просматривать, обнаруживать и управлять образами вашего проекта. Проблема в том, что удаление тега было самым затратным действием на GitLab.com, причем выполнение некоторых запросов занимало до 60 секунд. Это приводило к замедлению загрузки страниц и увеличению количества запросов в службу поддержки.
В GitLab 12.8 мы рады сообщить, что мы улучшили производительность этой функции примерно на 70%. Это сократит время загрузки страницы и повысит надежность.
Документация по реестру контейнеров и оригинальный тикет.
Перетаскивание значков дизайна
(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: “Create”
При просмотре дизайна на вкладке Дизайн данного тикета вы можете добавить значки комментариев в любую область изображения и прикрепить комментарий. Это отлично подходит для обсуждения интересующих вопросов. Тем не менее, когда вы получаете обратную связь и загружаете новые ревизии, иногда вам нужно переместить значок на новое место. В этом релизе уже можно перетаскивать значки. А еще теперь вы можете:
- Перетащить значок комментария после того, как отпустили его.
- Переместить чужой значок, чтобы соответствовать вашим.
- Переместить значки в соответствии с новым дизайном после внесения изменений в макет.
Документация по управлению дизайнами и добавлению комментариев и оригинальный тикет.
Отображение пространства имен Kubernetes на странице задания
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”
Когда задание CI/CD развертывается в окружении Kubernetes, страница сведений о задании теперь будет отображать пространство имен Kubernetes, используемое для этого развертывания. На странице сведений можно проверить, что рабочие нагрузки развернуты в нужное окружение.
Документация по конвейерам и оригинальный тикет.
Ускоренный браузер репозитория
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Изучение исходного кода проекта, который вы впервые видите, или проекта, в который вы вносите свой вклад, теперь будет происходить быстрее. В GitLab 12.8 при пролистывании директорий список файлов и данные коммитов обновляются без перезагрузки всей страницы, что избавляет от ненужной загрузки страниц.
Документация по репозиторию проекта и оригинальный эпик.
Настройка ширины табов
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
В отличие от пробелов, табы (символы табуляции) для некоторых не просто дело вкуса. Для тех, кто использует табы, их правильная ширина существенна. В частности, для проектов на языках C и Go, где табы наиболее распространены, важно, чтобы ширину табов можно было настроить в соответствии с локальными предпочтениями для лучшего ревью кода.
Теперь GitLab предоставляет пользовательский параметр Tab width, используемый при просмотре кода, включая диффы, логи CI и визуализированные блоки кода в Markdown.
Спасибо Alexander Oleynikov за этот вклад!
Документация по настройке ширины табов и оригинальный тикет.
Изменения в мерж-реквесте загружаются постепенно
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”
Мерж-реквесты, особенно вкладка Изменения (Changes) — это место, где проводят ревью и обсуждение исходного кода. Раньше, когда предлагаемых изменений становилось много, дифф загружался медленно и его нельзя было прочитать до полной загрузки.
В GitLab 12.8 список изменений файлов загружается сразу, а сами диффы загружаются постепенно. В итоге вы можете начать просматривать диффы почти сразу, а не ждать полной загрузки страницы.
Документация по работе с мерж-реквестами и оригинальный тикет.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.8 released with Log Explorer, NuGet, and Compliance.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.
