LOST by sophiagworld

В этой статей собраны некоторые общие шаблоны, помогающие инженерам работать с масштабными сервисами, к которым делают запросы миллионы пользователей.

По опыту автора, это не исчерпывающий список, но действительно эффективные советы. Итак, начнем.

Переведено при поддержке Mail.ru Cloud Solutions.

Начальный уровень

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

Инфраструктура как код

Первая часть советов заключается в том, чтобы реализовать инфраструктуру как код. Это означает, что у вас должен быть программный способ развертывания всей инфраструктуры. Звучит замысловато, но на самом деле мы говорим о следующем коде:

Развертывание 100 виртуальных машин

• с Ubuntu
• 2 ГБ RAM на каждой
• у них будет следующий код
• с такими параметрами

Вы можете отслеживать изменения в инфраструктуре и быстро возвращаться к ним с помощью системы управления версиями.

Модернист во мне говорит, что можно использовать Kubernetes/Docker, чтобы сделать всё выше перечисленное, и он прав.

Кроме того, обеспечить автоматизацию, можно с помощью Chef, Puppet или Terraform.

Непрерывная интеграция и доставка

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

Каждый раз на этом этапе вы отвечаете на вопрос: будет ли моя сборка компилироваться и проходить тесты, валидна ли она? Это может показаться низкой планкой, но решает множество проблем.


Нет ничего прекраснее, чем видеть эти галочки

Для этой технологии можете оценить Github, CircleCI или Jenkins.

Балансировщики нагрузки

Итак, мы хотим запустить балансировщик нагрузки, чтобы перенаправлять трафик, и обеспечить равную нагрузку на всех узлах или работу сервиса в случае сбоя:


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

Обычно балансировщики нагрузки настраиваются в том облаке, которым вы пользуетесь.

RayID, сorrelation ID или UUID для запросов

Вам когда-нибудь встречалась ошибка в приложении с сообщением вроде такого: Что-то пошло не так. Сохраните этот id и отправьте его в нашу службу поддержки?


Уникальный идентификатор, correlation ID, RayID или любой из вариантов это уникальный идентификатор, который позволяет отслеживать запрос в течение его жизненного цикла. Это позволяет отследить весь путь запроса в логах.


Пользователь делает запрос к системе A, затем А связывается с B, та связывается с C, сохраняет в X и затем запрос возвращается в A

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

Средний уровень

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

Централизованное ведение журналов

Поздравляю! Вы развернули 100 виртуальных машин. На следующий день генеральный директор приходит и жалуется на ошибку, которую получил во время тестирования сервиса. Он сообщает соответствующий идентификатор, о котором мы говорили выше, но вам придется просматривать журналы 100 машин, чтобы найти ту, которая вызвала сбой. И ее нужно найти до завтрашней презентации.

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


Функциональность стека ELK

Агенты мониторинга

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

На этом этапе вы проверяете, что запущенная сборка хорошо себя чувствует и нормально работает.

Для небольших и средних проектов я рекомендую Postman для мониторинга и документирования API. Но в целом просто следует убедиться, что у вас есть способ узнать, когда произошел сбой, и получить своевременное оповещение.

Автомасштабирование в зависимости от нагрузки

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


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

Система экспериментов

Хорошим способом безопасно развернуть обновления станет возможность протестировать что-то для 1% пользователей в течение часа. Вы, конечно, видели такие механизмы в действии. Например, Facebook показывает части аудитории другой цвет или меняет размер шрифта, чтобы посмотреть, как пользователи воспринимают изменения. Это называют A/B-тестированием.

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

Продвинутый уровень

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

Сине-зеленые развертывания

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

Этот шаг зависит от наличия балансировщика нагрузки. Представим, что у вас версия N вашего программного обеспечения, а затем вы хотите развернуть версию N+1.

Вы могли бы просто остановить службу и развернуть следующую версию в то время, которое считаете удобным для ваших пользователей, и получить некоторое время простоя. Но предположим, что у вас действительно строгие условия SLA. Так, SLA 99,99% означает, что вы можете уходить в офлайн только на 52 минуты в год.

Если вы действительно хотите достичь таких показателей, нужно два деплоя одновременно:

• тот, который есть прямо сейчас (N);
• следующая версия (N+1).

Вы указываете балансировщику нагрузки перенаправить процент трафика на новую версию (N+1), в то время как сами активно отслеживаете регрессии.


Здесь у нас есть зеленый деплой N, который нормально работает. Мы пытаемся перейти к следующей версии этого деплоя

Сначала мы посылаем действительно небольшой тест, чтобы посмотреть, работает ли наш деплой N+1 с небольшим количеством трафика:


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


Если хотите перейти на еще более продвинутый уровень, пусть всё в сине-зеленом деплое выполняется автоматически.

Обнаружение аномалий и автоматическое смягчение последствий

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


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

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

Вот и всё!

Этот список приоритетов избавит вас от многих проблем, если вы поднимаете облачный сервис.

Автор оригинальной статьи приглашает читателей оставлять свои комментарии и вносить изменения. Статья распространяется как open source, пул-реквесты автор принимает на Github.

Что еще почитать по теме:

1. Go и кэши CPU.
2. Kubernetes в духе пиратства с шаблоном по внедрению.
3. Наш канал Вокруг Kubernetes в Телеграме.

Что изменилось со времени 12.0

Прежде чем приступить к описанию нового мажорного релиза 13.0, мы хотели бы уделить внимание пройденному пути. Мы столького достигли с момента выхода версии 12.0! Недавно в блоге вышел специальный пост, в котором мы сделали обзор релизов GitLab с 12.0 по 12.10. Три наших фаворита из этой серии релизов это управление требованиями, сетевая безопасность контейнеров и конвейеры (в русской локализации GitLab сборочные линии) родитель-ребенок.

В дополнение к улучшениям самого продукта мы также обновили наши партнерские программы и интеграции, добавили рекомендации по интеграции для использования сторонних сканеров безопасности, а также расширили наши пакеты услуг техподдержки, чтобы помочь вам с такими вещами, как миграции Jira и Jenkins. На нашем новом видеоканале Learn@GitLab вы найдете множество видеоуроков. Например, Начало работы с CI.

Итерации ключ к устойчивости

GitLab помогает ИТ- и бизнес-командам развиваться, вовремя реагировать и адаптироваться, и ключ ко всему этому итерации. Пользователям необходимо быстро взаимодействовать, оптимизировать работу и автоматизировать процессы для обеспечения безопасности и соответствия требованиям, не забывая при этом о качестве продукта. GitLab 13.0 поможет вам итерировать быстро и с более глубоким пониманием процесса. Доступ к Git-репозиториям также является критически важным, и мы усовершенствовали наш кластер Gitaly для высокодоступных (HA) хранилищ Git, чтобы в случае сбоя всегда имелось несколько свежих и готовых к работе реплик.

Оперативное реагирование и сотрудничество всей команды

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

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

Оптимизация для повышения эффективности

Поскольку многие компании стремятся быть более оперативными и более эффективными, GitLab старается упростить существующие процессы разработки программного обеспечения. Новые фичи, направленные на повышение эффективности, включают в себя упрощенное развертывание на Amazon ECS и новый объединенный список оповещений, который объединяет IT-оповещения, поступающие из нескольких источников, в едином интерфейсе. Кроме того, у нас есть хорошая новость и для пользователей Terraform. В GitLab 13.0 появился краткий обзор результата terraform plan в мерж-реквестах (в русской локализации GitLab запросы на слияние) и использование GitLab в качестве бэкенда для state файла.

Доверяйте вашим процессам и не жертвуйте безопасностью и соответствием требованиям

GitLab помогает компаниям комплексно внедрять средства контроля безопасности и соответствия требованиям в жизненный цикл разработки ПО, снижая риски и высвобождая ресурсы для критически важных потребностей бизнеса. Наши возможности тестирования безопасности приложений помогают вам быстрее находить и исправлять уязвимости безопасности, благодаря чему GitLab недавно был назван нишевым игроком в Gartner Magic Quadrant for Application Security Testing 2020 года.

С момента оценки Gartner релиза 12.4 мы добавили много новых фич. А в 13.0 мы добавили возможность сканирования REST API через DAST и полное сканирование истории коммитов на наличие секретных ключей. Более того, мы поменяли наш способ работы с объектами уязвимостей. Благодаря этому появилась возможность экспортировать уязвимости из панели безопасности и в будущем будут доступны более широкие возможности управления уязвимостями.

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

А что впереди?

Мы с энтузиазмом готовим предстоящие релизы, в частности, фичи, которые помогут вам:

• Обеспечить соответствие требованиям и автоматически применять соответствующие меры контроля и отчетности.
• Получать больше инсайтов благодаря выпуску версий с A/B-тестированием и контролировать их с помощью нескольких улучшений для переключаемых фич фильтрация фич по статусу, A/B-тестирование на основе переключаемых фич и возможность создавать переключаемые фичи из мерж-реквеста).
• Определять узкие места и потери благодаря отображению стадий в аналитике цикла разработки в виде потока.
• Управлять правилами и оставлять GitLab автоматизацию их использования, включая готовый набор сетевых правил безопасности контейнера.
• Тестировать API приложений фаззингом, а также считывать переменные CI из хранилища HashiCorp.

Хотите увидеть полный список того, что выйдет в следующем месяце? Наша дорожная карта открыта и всегда доступна для всех желающих внести свой вклад.

Теперь, без лишних слов, приступим к описанию всех классных фич релиза 13.0!

Приглашаем на наши встречи.

MVP этого месяца Sashi

Sashi добавил огромное количество улучшений в релиз 13.0 в различных разделах GitLab. Его работа помогла улучшить контроль версий сниппетов, удалить ошибки, связанные с тегом Releases, и минимизировать дублирование событий, посылаемых веб-хуками. Также он улучшил структуру и читаемость кода, обеспечив каждому формату пакета уникальную модель для хранения метаданных.

Спасибо Sashi за всю эту работу!

Ключевые фичи релиза GitLab 13.0

Кластер Gitaly для высокодоступных хранилищ Git

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

GitLab теперь поддерживает высокодоступные системы хранения Git без использования NFS. Конфигурации высокой доступности (high availability, HA) повышают доступность важных систем, таких как хранилища Git, за счет устранения единичных точек отказа, обнаружения сбоев и автоматического переключения на реплику. Это означает, что отдельный компонент системы может выйти из строя, не вызвав сбоя у конечного пользователя. Доступ к репозиториям Git очень важен для разработчиков и компаний, поскольку при его выходе из строя разработчики не смогут отправлять код и развертывание будет заблокировано.

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

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

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

Автоматическое развертывание в ECS

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

До сих пор у нас не было простого способа развертывания в Amazon Web Services. Из-за этого пользователям GitLab приходилось тратить много времени на настройку собственной конфигурации.

В GitLab 13.0 поддержка развертывания в AWS уже ждет вас в Auto DevOps! Пользователи GitLab, которые развертывают в Elastic Container Service (ECS) от AWS, теперь могут воспользоваться возможностями Auto DevOps, даже если они не используют Kubernetes. Auto DevOps упрощает и ускоряет поставку и облачное развертывание с помощью полного конвейера поставки сразу из коробки. Благодаря устранению лишних сложностей вы сможете сконцентрироваться на аспектах создания программного обеспечения. Просто отправьте коммит, а GitLab сделает все остальное!

Чтобы подключить эту фичу, необходимо определить переменные окружения для AWS: AWS_ACCESS_KEY_ID, AWS_ACCOUNT_ID и AWS_REGION, а также включить Auto DevOps. Затем ваше развертывание ECS будет автоматически собрано для вас с полным автоматическим конвейером поставки.

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

Просмотр иерархии эпиков на дорожной карте

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

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

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

Контроль версий для сниппетов

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

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

Теперь сниппеты в GitLab также находятся под контролем версий в Git-репозитории. При редактировании сниппета каждое изменение создает коммит. Сниппеты также можно клонировать для локального редактирования, а затем отправлять в репозиторий Snippet.

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

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

Темная тема в Web IDE

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

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

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

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

Отдельные объекты уязвимостей

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

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

Одно из самых больших преимуществ заключается в том, что теперь каждая уязвимость будет иметь уникальный URL. Это означает, что на уязвимость можно ссылаться напрямую, делиться ей и отслеживать ее как единый источник информации. На этой странице вы можете изменить статус уязвимости на Обнаружена ("Detected"), Подтверждена ("Confirmed"), Проигнорирована ("Dismissed") или Решена ("Resolved"). Еще одним преимуществом является то, что обнаруженные уязвимости будут сохраняться при следующем запуске сканера. Ранее запуск сканирования на той же ветке перезаписывал все предыдущие результаты новыми. Сохранение прошлых объектов уязвимостей улучшит качество отслеживания, наглядность и сократит дублирование результатов между прогонами сканера. Кроме того, это даст в будущем возможность создавать отчеты о тенденциях уязвимостей в группах и проектах с течением времени по широкому ряду параметров.

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

Поддержка REST API в сканированиях DAST

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

В GitLab 13.0 мы добавили DAST сканирования REST API. Это позволит обеспечить полное DAST-покрытие безопасности всего приложения, а не только пользовательского интерфейса. DAST поддерживает использование спецификации OpenAPI в качестве руководства по сканированию URL-адресов и конечных точек REST, что позволит обеспечить безопасность всех направлений атак и даст больше информации о потенциальных уязвимостях любого работающего приложения.

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

SAST для .NET Framework

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

Мы представляем начальную поддержку .Net Framework, которая позволит разработчикам запускать сканирования безопасности SAST в дополнительных типах .NET проектов. Как и в других наших заданиях SAST, в них будут использоваться обработчики заданий GitLab (runner) для Linux. В будущем мы планируем добавить поддержку обработчиков заданий Windows. С момента появления в GitLab 11.0, SAST для .NET включал в себя поддержку только для проектов .NET Core.

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

Краткий обзор результата terraform plan в мерж-реквестах

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

Если вы используете Terraform для определения вашей инфраструктуры в виде кода, вы знаете, как удручает необходимость постоянно передавать коллегам итоговые изменения из команды terraform plan в slack и комментариях в мерж-реквестах. В GitLab 13.0 теперь вы будете видеть краткий обзор вывода команды terraform plan в том контексте, где это наиболее полезно непосредственно в вашем мерж-реквесте. Это поможет вам быстрее проверять изменения в вашей инфраструктуре и предоставит удобное место для взаимодействия с членами вашей команды по предполагаемому влиянию на вашу инфраструктуру по мере изменения кода.

Пользователи шаблона Terraform, предлагаемого GitLab, увидят виджет мерж-реквеста terraform plan без какой-либо дополнительной настройки. Пользователи персонализированных шаблонов CI/CD могут обновить свой шаблон, чтобы использовать образ и скрипты официального шаблона Terraform от GitLab.

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

Использование GitLab в качестве бэкенда для state файла Terraform

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

Пользователи Terraform прекрасно знакомы с трудностями настройки state файла (карта связей вашей конфигурации с реальными ресурсами, в которой также отслеживаются дополнительные метаданные). Этот процесс включает в себя создание нового проекта Terraform и настройку стороннего бэкенда для хранения надежного, безопасного и не зависящего от вашего git-репозитория файла состояния.

Многие пользователи искали более простой способ настройки файлового хранилища без использования дополнительных сервисов или настроек. Начиная с GitLab 13.0 как HTTP-бэкенд для Terraform можно использовать сам GitLab, что устраняет необходимость настраивать отдельное хранилище для state файлов для каждого нового проекта.

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

HTTP-бэкенд для состояний Terraform от GitLab поддерживает:

• Многочисленные именованные файлы состояния в одном проекте
• Блокировку
• Хранилище объектов
• Шифрование в состоянии покоя

Все это теперь доступно и для пользовательских инстансов GitLab, и на GitLab.com.

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

Исключайте большие файлы с помощью частичного клонирования

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

Хранение больших бинарных файлов в Git обычно не приветствуется, поскольку все добавленные файлы будут загружены каждым, кто впоследствии клонирует или проверяет обновления (git fetch) репозитория. Это сильно замедляет, если вовсе не останавливает, работу при медленном или ненадежном соединении.

В GitLab 13.0 частичное клонирование было включено для фильтров по размеру блоба, а также экспериментально для других фильтров. Это позволяет исключить проблемные большие файлы из клонирований и скачиваний обновлений. Когда Git обнаруживает недостающий файл, он будет загружен по требованию. При клонировании проекта используйте --filter=blob:none для полного исключения блобов или --filer=blob:limit=1m для исключения по размеру файла. Обратите внимание, что для частичного клонирования требуется версия Git не ниже 2.22.0.

Узнайте все подробности в нашем недавнем посте Как частичное клонирование в Git позволяет вам получать только необходимые большие файлы.

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

Управление панелями метрик через переменные

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

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

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

Сниженное потребление памяти GitLab с Puma

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

Puma теперь по умолчанию является сервером веб-приложений для установок на основе Omnibus и Helm. Puma снижает объем памяти, потребляемой GitLab, примерно на 40% по сравнению с Unicorn, что повышает эффективность работы GitLab и позволяет потенциально сэкономить на стоимости инстансов с самостоятельным управлением.

Установкам, которые настроили количество процессов Unicorn, или используют более медленные диски с NFS, возможно придется изменить конфигурацию Puma по умолчанию. Посмотрите важные заметки по обновлениям и улучшения в GitLab chart, чтобы узнать больше.

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

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

Фильтр для поиска по событиям аудита в инстансе

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

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

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

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

Включение защиты веток по умолчанию на уровне группы

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

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

Теперь защиту веток по умолчанию можно настроить на уровне группы, чтобы предоставить большую гибкость для администраторов и владельцев групп. Используя комбинацию защиты веток по умолчанию и настроек создания проекта по умолчанию, организации смогут найти нужный баланс между автономией и контролем. Например, использовать свои настройки для защиты веток по умолчанию и разрешать создавать новые проекты только пользователям с ролями maintainer. Это позволит разработчикам добавлять новые коммиты (без принудительного пуша или удаления веток) к новым проектам, при этом оставляя создание проектов maintainers.

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

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

Аналитика цикла разработки: график задач по типу

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

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

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

Email-уведомления при авторизации из неизвестного источника

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

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

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

Предупреждение при закрытии тикета с неразрешенными зависимостями

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

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

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

Эти уведомления о зависимостях позволят вашим проектам работать без заминок, а также обеспечат правильную последовательность тикетов.

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

Более удобное добавление эпиков и тикетов через дерево эпиков

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

Создание и добавление тикетов и эпиков через дерево эпиков ранее было разделено по нескольким кнопкам и выпадающим меню, и поэтому его было неудобно использовать. Мы объединили действия add (добавить) и create (создать) в отдельную кнопку с меню, чтобы добавлять новые тикеты и эпики было проще и быстрее!

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

Эмодзи в обсуждении дизайнов

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

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

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

Новый режим сравнения для мерж-реквестов

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

Мерж-реквесты, особенно вкладка Изменения (Changes), это место, где происходит обсуждение и ревью исходного кода. В случаях, когда целевая ветка была смержена в исходную ветку мерж-реквеста, изменения в исходной и целевой ветках могут оказаться перемешанными, из-за чего становится сложно понять, какие изменения добавляются, а какие уже существуют в целевой ветке.

В GitLab 13.0 мы добавляем экспериментальный режим сравнения. Он будет показывать дифф, рассчитанный путем симуляции мержа, что даст более точное представление изменений, чем использование мержей обеих веток. Этот режим доступен в выпадающем меню ветки, выбранной для сравнения через пункт master (HEAD). В будущем этот режим заменит текущий способ сравнения по умолчанию.

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

Темы подсветки синтаксиса для Web IDE

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

GitLab поддерживает шесть тем подсветки синтаксиса при просмотре кода. Темы крайне важны для удобства разработчиков при просмотре и редактировании кода в GitLab. Теперь мы добавили поддержку всех шести тем подсветки синтаксиса в Web IDE, включая Solarized Dark, Solarized Light, Monokai и режим без подсветки.

На протяжении нескольких последних релизов (например, в 12.8 и 12.9) мы добавляли и улучшали поддержку тем подсветки в Web IDE. Новые темы подсветки являются продолжением этой работы и помогли заложить основу для нашей темной темы в Web IDE, которая также выходит в 13.0. Мы продолжаем улучшать интерфейс для разработчиков и делать нашу Web IDE более комфортной.

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

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

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

Когда над одним дизайном ведется много обсуждений, становится сложно определить, какие обсуждения относятся к какому пину, без поиска номера этого комментария.

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

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

Правила пушей для групп

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

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

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

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

Кнопки навигации по коммитам в мерж-реквестах

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

Удобная навигация по коммитам в больших мерж-реквестах позволяет более эффективно проводить ревью с перемещением между коммитами.

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

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

Доступ к отчетам JUnit через API GitLab

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

Отчет JUnit может содержать информацию для обновления планов тестирования, истории выполнения тестов и других артефактов, которые команды используют, чтобы следить за качеством своего кода. Обновление этих артефактов может быть долгим и утомительным процессом. Что еще хуже, отчеты были JUnit доступны только путем скачивания через пользовательский интерфейс GitLab. Начиная с версии GitLab 13.0 пользователи API GitLab смогут получать доступ к отчетам JUnit напрямую. Это позволит пользователям парсить данные JUnit для создания новых тикетов или обновления истории выполнения тестов.

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

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

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

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

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

Доступ к реестру пакетов GitLab для чтения или записи через токены развертывания

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

Токены развертывания позволяют вам получать доступ к репозиториям группы, репозиториям проекта и реестрам контейнеров. Команды read_repository, read_registry и write_registry ранее не позволяли вам получать доступ к реестру пакетов GitLab. В результате командам DevOps приходилось использовать небезопасные или дорогостоящие обходные пути.

В GitLab 13.0 мы добавили более точные настройки разрешений токенов развертывания GitLab. Теперь вы можете задавать доступ к реестру пакетов для чтения или записи. Создавать токены развертывания и управлять ими можно из приложения GitLab или через API.

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

Все версии пакета под одним именем

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

Реестр пакетов GitLab ранее рассматривал каждую новую версию пакета как новый пакет. Из-за этого было сложно искать нужные пакеты или сравнивать изменения между разными версиями пакета.

В GitLab 13.0 каждая версия пакета будет находиться под родительским пакетом с уникальным именем. Это упростит поиск нужного пакета через пользовательский интерфейс и просмотр изменений между версиями. Это обновление применяется для уровней групп и проектов в реестре пакетов. Кроме того, при использовании API пакетов версии пакета будут возвращаться как массив под именем родительского пакета.

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

Заморозка развертывания через API Freeze Period

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

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

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

Обновление майлстоунов релиза через пользовательский интерфейс GitLab

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

Команда управления разделом Релизов GitLab работает над расширением страницы релиза для использования всей функциональности API релизов. В версии 13.0 стало проще добавлять один или несколько майлстоунов к вашим релизам. С этим обновлением вам больше не придется вручную вызывать API релизов, чтобы пользоваться фичами для планирования, такими как просмотр прогресса по релизу, который был представлен в версии 12.9.

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

Поиск образов по имени в реестре контейнеров GitLab

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

Когда вы или кто-то в вашей команде публикует образ в реестр контейнеров GitLab, вам нужен способ быстро найти этот образ и убедиться, что он был собран правильно. Раньше, если вы использовали GitLab CI/CD для публикации образов с каждой сборкой, через пользовательский интерфейс было сложно эффективно проводить поиск образов. Вместо этого вам приходилось полагаться на командную строку или API.

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

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

Просмотр нагрузки и аннотаций внешних IT-уведомлений в GitLab

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

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

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

Рендер эмодзи на странице состояния проекта

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

Тикеты GitLab поддерживают эмодзи в имени тикета и во всех полях с поддержкой Markdown. Теперь при публикации тикета через публичный URL как страницы статуса проекта на этой странице поддерживаются и рендерятся эмодзи, использованные в имени, описаниях и комментариях к тикету.

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

Переключение видимости панели метрик

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

Ранее администраторы проекта не могли управлять разрешениями на просмотр панели метрик проекта. В GitLab 13.0 администраторы смогут разрешать видимость панели метрик либо только участникам проекта, либо всем пользователям с правами доступа.

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

Добавление аннотаций на панель метрик

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

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

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

Поиск секретных ключей в полной истории репозитория

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

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

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

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

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

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

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

Теперь вы можете загружать файл в формате CSV со всеми обнаруженными уязвимостями для определенного проекта или для всех проектов, управляемых на панели безопасности инстанса. Этот список можно использовать для создания отчетов по безопасности или как источник данных для внешних панелей безопасности. Просто перейдите к панели безопасности инстанса или к панели безопасности любого проекта и нажмите новую кнопку Export справа вверху или выберите Security в меню More на верхней панели навигации, затем нажмите новую кнопку Export в правом верхнем углу. Ваш браузер автоматически начнет загрузку.

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

Интеграция SIEM с файерволом веб-приложений

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

Мы объявляем о новой интеграции SIEM для файервола веб-приложений (WAF). Эта интеграция позволяет пользователям экспортировать свои логи WAF в SIEM или в централизованное решение для логирования, чтобы можно было просматривать любые аномалии, обнаруженные WAF. Эта фича также облегчает пользователям тестирование и настройку пользовательских правил WAF, что уменьшает количество ложных срабатываний. Интеграцию SIEM можно настроить, включив Fluentd на странице Операции > Kubernetes (Operations > Kubernetes).

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

Вторичные ноды Geo автоматически пересылают запросы SSH для несинхронизированных репозиториев

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

Geo поддерживает выборочную синхронизацию проектов, что позволяет системным администраторам выбирать подмножество данных, реплицируемое во вторичные ноды Geo. Geo уже поддерживает перенаправление запросов HTTP(S) на основной сервер при попытке доступа к этим несинхронизированным репозиториям. Однако пользователи, пытавщиеся получить доступ к несинхронизированным репозиториям на вторичной ноде через SSH, получали сообщение об ошибке, что репозиторий недоступен. Это сбивало с толку пользователей и заставляло их либо ждать синхронизации хранилища, либо выполнять дополнительную работу для подключения к нужному хранилищу.

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

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

Обработчик заданий теперь поддерживает загрузку артефактов непосредственно из хранилища объектов

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

Обработчик заданий GitLab (GitLab Runner) 13.0 теперь поддерживает загрузку артефактов непосредственно из хранилища объектов. Когда эта опция включена, сервер GitLab будет перенаправлять обработчик заданий непосредственно в хранилище объектов, а не проксировать трафик. Это может привести к значительной экономии затрат на передачу по сети, а также к снижению нагрузки на сервер GitLab.

Для подключения установите переключаемую фичу FF_USE_DIRECT_DOWNLOAD в true через переменную окружения.

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

Добавлены события аудита для действий администратора под именем пользователя

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

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

Это важное дополнение к событиям аудита исправляет пробел в неоспоримости действий (nonrepudiation) для вашей программы соответствия требованиям и повышает надежность и полноту данных о событиях аудита GitLab.

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

Аналитика цикла разработки: метрики для времени выполнения и времени цикла

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

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

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

Приложение интеграции Okta SCIM для GitLab.com

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

Теперь мы предлагаем приложение интеграции Okta SCIM для групп на Gitlab.com. Когда Okta SCIM настраивается для группы GitLab, членство в этой группе синхронизируется между GitLab и Okta. Это экономит время администратора группы, затрачиваемое на добавление и удаление пользователей.

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

Экспорт и импорт групп в пользовательском интерфейсе

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

Ранее пользователи могли переносить группы только с помощью API экспорта и импорта: сначала требовалось создать файл экспорта, а затем снова с помощью API загрузить файл в нужный инстанс.

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

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

Просмотр майлстоунов на дорожной карте

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

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

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

Перетаскивание тикетов между эпиками в дереве эпиков

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

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

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

Управление дизайнами теперь в Core

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

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

Так что теперь все пользователи могут загружать дизайны и давать обратную связь по дизайну в тикетах GitLab. Напоминаем, что вы найдете вкладку Дизайн (Design) рядом с вкладкой Обсуждение (Discussion) в любом тикете. Для начала попробуйте загрузить скриншот с помощью перетаскивания.

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

Улучшенный редактор сниппетов

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

С выпуском сниппетов с поддержкой версий в GitLab 13.0 мы обновили редактор сниппетов до более легкой версии редактора из нашей Web IDE. С помощью этого редактора пользователи смогут воспользоваться базовым дополнением кода и статическим анализом (линтингом) для некоторых языков. Мы также улучшили определение языка исходного кода для лучшей подсветки синтаксиса и добавили поддержку для всех наших тем подсветки синтаксиса. Эти улучшения облегчат редактирование и совместную работу над сниппетами.

Мы рады обеспечить согласованность редактора сниппетов и редактора в Web IDE. В следующем релизе мы добавим эти возможности также для нашего редактора одиночного файла и редактирования файла .gitlab-ci.yml.

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

WYSIWYG для редактора статических сайтов

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

Markdown это мощный и эффективный синтаксис для создания веб-контента. Но даже опытные авторы контента в Markdown могут подзабыть некоторые из редко используемых параметров форматирования или с трудом пишут даже умеренно сложные таблицы с нуля. Некоторые работы удобнее выполнять с помощью визуального редактора что видите, то и получите (WYSIWYG).

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

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

Фильтр Approved-by для мерж-реквестов

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

Утверждение мерж-реквеста требует, чтобы определенные люди одобрили изменения, прежде чем их можно будет смержить. При поиске в списке мерж-реквестов вы можете быстро найти, какие из них нуждаются в вашем одобрении, с помощью фильтра Утверждающие (Approvers). В GitLab 13.0 теперь вы также сможете найти любые ранее одобренные вами мерж-реквесты, используя новый фильтр Approved-By.

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

Поддержка родительских групп и пользователей в файле CODEOWNERS

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

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

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

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

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

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

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

Теперь можно передавать переменные окружения и другие данные между заданиями CI. Используя ключевое слово dependencies (или ключевое слово needs для конвейеров DAG), задание может наследовать переменные от других заданий, если они получены с помощью артефактов отчета dotenv. Это предлагает более изящный подход для обновления переменных между заданиями по сравнению с использованием артефактов или передачей файлов.

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

Настраиваемый порог тестирования производительности браузера

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

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

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

Просмотр более надежных данных в списке в пользовательском интерфейсе реестра пакетов

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

До этого релиза в списочном представлении реестра пакетов отображался ограниченный объем информации, относящейся к пакетам. Хотя эта информация важна, в ней отсутствовали ключевые метаданные, такие как версия, ветка и коммит.

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

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

Просмотр всех ваших пакетов Python в одном месте с помощью реестра пакетов GitLab

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

Пользовательский интерфейс реестра пакетов GitLab позволяет вам подтвердить, что ваши пакеты были собраны правильно, и устранить неполадки, если что-то пошло не так. Однако MVC нового репозитория PyPI, запущенного в 12.10, не включал эту функциональность.

В версии 13.0 мы добавили репозиторий PyPI в пользовательский интерфейс реестра пакетов. Теперь вы можете просматривать и загружать пакеты PyPI вашего проекта или группы и проверять метаданные и правильность сборки пакета. Вы также можете скопировать команды настройки и установки для более эффективного совместного использования и разработки. Если пакет был собран с использованием конвейера GitLab, вы сможете просмотреть и связать его с конвейером, а также с коммитом, который использовался для публикации пакета.

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

Поддержка API для списков переключаемых фич

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

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

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

Определите правила, чтобы важные образы никогда не удалялись

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

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

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

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

Используйте облачные пакеты сборки для Auto DevOps (бета-версия)

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

Облачные пакеты сборки являются следующей итерацией пакетов сборки. В то время как GitLab в настоящее время по умолчанию использует пакеты сборки Herokuish, мы намерены перевести Auto DevOps на облачные пакеты сборки, когда проект созреет, чтобы предоставить нашим пользователям надежное и хорошо поддерживаемое решение. В этом релизе вы можете выбрать использование бета-версии облачных нативных пакетов сборки в конвейерах Auto DevOps, установив переменную CI AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED.

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

Агрегирование оповещений из внешних инструментов в GitLab

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

При реагировании на предупреждения респондентам необходим единый интерфейс, объединяющий IT-оповещения, поступающие из нескольких источников. Новый список оповещений позволяет быстро и интуитивно сортировать оповещения, чтобы в первую очередь найти и проанализировать наиболее важные проблемы. Вы можете найти список предупреждений в Операции > Оповещения (Operations > Alerts).

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

Добавьте часто используемые панели мониторинга в избранное

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

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

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

Отображение графиков в полноэкранном режиме

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

В GitLab 13.0 теперь можно отображать графики метрик в полноэкранном режиме, что позволяет более подробно рассмотреть информацию на них при сортировке инцидентов.

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

Анонимизация на страницах статуса

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

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

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

Просмотр списка просканированных DAST ресурсов

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

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

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

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

Интеграции SIEM для правил контейнерных сетей

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

Мы представляем новую интеграцию SIEM для правил сетевой безопасности контейнеров. Интеграция позволяет пользователям экспортировать свои логи Cilium в SIEM или в централизованное решение для логирования, чтобы они могли просматривать любые аномалии, обнаруженные их сетевыми правилами. Просмотр журналов также помогает пользователям тестировать и настраивать свои сетевые правила, чтобы снизить вероятность ложных срабатываний. Интеграцию SIEM можно настроить на странице Операции > Kubernetes (Operations > Kubernetes).

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

Оперативная информация о базе данных уязвимостей

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

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

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

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

PostgreSQL 11 теперь минимально необходимая версия для установки GitLab

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

Теперь минимальной требуемой версией PostgreSQL для всех пользовательских инстансов стала PostgreSQL 11. PostgreSQL версий 9.6 и 10 были удалены в GitLab 13.0. Это обновление позволяет нам начать вводить улучшения производительности на основе функций разбиения на разделы, которые были добавлены в PostgreSQL 11. Мы планируем поддерживать PostgreSQL 11 на протяжении всей серии релизов GitLab 13.x. Поддержка PostgreSQL 12 будет добавлена в ближайшее время. Посмотрите важные замечания по обновлению для получения инструкций по обновлению PostgreSQL.

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

Улучшена производительность репликации Geo для артефактов заданий, загрузок и файлов LFS

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

Чтобы определить, что нужно реплицировать с первичной базы данных, Geo сравнивает базу данных отслеживания с вторичной базой данных только для чтения. Если запросы к базе данных Geo выполняются слишком долго, то данные не могут быть успешно реплицированы. В GitLab 13.0 мы используем новый подход к синхронизации артефактов заданий и загрузок, тем самым исключая возможность таймаутов базы данных. Мы также улучшили производительность запросов к базе данных для извлечения артефактов заданий, объектов LFS и загрузок, когда эти файлы хранятся локально. Это повышает общую масштабируемость и производительность GitLab Geo.

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

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

---

Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 13.0 released with Gitaly Clusters, Epic Hierarchy on Roadmaps, and Auto Deploy to ECS.

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

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

Автоматизируйте и расширяйте управление оповещениями

Оповещения необходимы для обслуживания приложения, но изучение и сортировка всех выдаваемых оповещений могут значительно снизить производительность и время отклика. Система управления оповещениями в GitLab объединяет и упорядочивает оповещения всех ваших сервисов, упрощая их анализ и устранение, повышая производительность и помогая вам сразу же приступить к изучению и ликвидации критических проблем. Ключевые нововведения в 13.1 включают назначение оповещений, интеграцию Slack и создание GitLab To-Dos при назначении оповещений.

Улучшение качества кода

Скорость развертывания имеет значение только в том случае, если вы развертываете качественный код. Благодаря приоритизации тестов для недавно измененного кода разработчики смогут сразу же начать устранять ошибки, не выполняя при этом весь набор тестов. Отслеживание покрытия кода с течением времени позволяет выявить тенденции качества как для разработчиков, так и для менеджеров, а встроенный code intelligence увеличивает скорость и точность ревью кода, интегрируя справочные материалы непосредственно в GitLab.

Укрепление и повышение уровня безопасности и соответствия требованиям

Безопасность важна для всех, и мы стремимся сократить барьеры на пути к полностью безопасному и совместимому SDLC. Вот почему мы рады сообщить, что мы перевели SAST-сканирование Brakeman в план Core, предоставляя возможность сканировать исходный код на наличие известных уязвимостей каждому Rails разработчику, независимо от уровня плана. Для организаций, ориентированных на соблюдение требований, мы добавили пользовательский интерфейс управления правилами для сетевых правил контейнеров, а также включили экспорт уязвимостей на уровне группы в CSV-файл для аудита или дальнейшего внутреннего анализа. Кроме того, мы внесли пару UX-улучшений в панель безопасности, добавив сохранение фильтров и иконки состояния тикетов для поддержания контекста во время работы в этой панели.

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

Это лишь небольшая выборка из обновлений релиза 13.1. В нем мы также достигли важного рубежа в отношении сотрудничества с сообществом. В рамках этого релиза были приняты более 300 мерж-реквестов (в русской локализации GitLab запросы на слияние) от нашего обширного сообщества, и мы высоко ценим вклад каждого из вас! Читайте дальше, чтобы узнать больше о других замечательных улучшениях, таких, как виджеты мерж-реквестов для тестирования доступности, возможность пометить обсуждение в дизайне как решенное, уведомления об успешном завершении конвейера и многие другие!

Если вы хотите узнать, что вас ждет в следующем релизе, посмотрите наше видео по релизу 13.2.

Приглашаем на наши встречи.

MVP этого месяца Jacopo Beschi

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

Работа над этой фичей заняла около 8 месяцев и Jacopo справился с этой задачей отлично! Он получил подтверждение от 5 различных ревьюверов, отличные отклики от нас в GitLab и большой интерес от пользователей: более 30 голосов за этот тикет и почти 70 активных дискуссий, связанных с ним.

Jacopo, спасибо за этот потрясающий вклад, мы очень его ценим!

Основные фичи в GitLab 13.1

Управление оповещениями в GitLab

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

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

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

В релизе 13.2 и далее мы планируем улучшить рабочие процессы оповещений и реагирования на инциденты с помощью интеграции с PagerDuty, отображения соответствующих метрик и логов оповещений, ассоциирования с перечнями задач (runbook) и создания специального Alert Integration Builder, чтобы ваши операторы могли самостоятельно обслуживать и беспрепятственно интегрировать GitLab с любыми инструментами мониторинга. Ознакомиться с ходом нашей работы и предложить свои идеи для будущих улучшений можно в эпике (в русской локализации GitLab цель) по управлению оповещениями.

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

Настройка стратегий переключения фич для разных окружений

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

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

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

Виджет тестирования доступности в мерж-реквесте

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

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

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

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

Возможность пометить обсуждение в дизайне как решенное

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

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

С релизом 13.1 вы сможете отметить любой комментарий как Решенный (Resolved), что означает, что обсуждение по нему завершено. Пины завершенных обсуждений исчезнут из дизайна, так что вы сможете сосредоточиться на том, что осталось. И, конечно же, если вам нужно что-то пересмотреть, все ваши завершенные обсуждения будут доступны в области Решенные обсуждения (Resolved Comment) в нижней части боковой панели. Там вы сможете найти их и проверить, какая ревизия была применена в данной точке.

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

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

Ревью мерж-реквестов перенесены в Core

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

Первоначально представленные в GitLab 11.4 в плане Premium, ревью мерж-реквестов позволяют ревьюверам отправлять несколько комментариев одновременно, что снижает количество оповещений для автора мерж-реквеста, а также обеспечивают более целостный и упорядоченный процесс ревью.

С тех пор мы пересмотрели место этой фичи в нашей стратегии определения планов, нацеленной на покупателя. Теперь мы рады объявить, что в рамках релиза 13.1 эта фича перенесена в план Core.

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

Code Intelligence

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

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

Мы вдохновлялись огромной работой, проделанной нашими коллегами из Sourcegraph, и использовали формат LSIF. Благодаря этому встроенный в GitLab Code Intelligence теперь можно добавить в любой проект с помощью нового задания в файле .gitlab-ci.yml. Это задание будет отвечать за LSIF-отчет, после генерации которого вы будете видеть доступные действия Code Intelligence при наведении курсора на объекты в коде. С релизом 13.1 вам больше не понадобятся сторонние инструменты или IDE для этого.

Будущие итерации будут включать в себя возможность поиска ссылок, а также поддержку API. Вы можете следить за обновленями в эпике Code Intelligence.

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

Управление переключаемыми фичами через списки пользователей

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

GitLab раньше уже поддерживал возможность контролировать развертывание фич на основе ID пользователей. Однако многократно добавлять пользователей для каждой фичи или окружения может быть утомительно. Чтобы сделать этот процесс удобнее, мы добавили новую стратегию для переключаемых фич списки. Списки пользователей создаются и модифицируются с помощью API. После создания списка выберите стратегию list для вашей переключаемой фичи и соответствующий список. Если у вас уже есть созданные списки, вы сразу же сможете ими воспользоваться.

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

График изменения покрытия кода в проекте

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

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

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

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

Специальное задание CI для управления требованиями

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

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

Мы рады представить первый шаг в этом направлении: возможность настроить в рамках стандартного CI-конвейера задания, которые при запуске будут отмечать все существующие требования как выполненные. Такое CI-задание может быть как ручным, так и автоматическим. А еще, как и другие задания CI, его можно настроить на разрешение неудачных выполнений (allow-failure), чтобы это задание не блокировало успешное завершение всего конвейера.

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

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

Параметр expires_at в конечной точке /user/keys

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

Спасибо Petar Prokic (@pprokic) за этот вклад от сообщества!

Конечные точки в API пользователей /user/keys и /users/:id/keys теперь поддерживают опциональный параметр expires_at для определения даты истечения срока действия SSH-ключей. Это изменение поможет пользователям и организациям управлять последствиями в случаях скомпрометированных учетных записей в контролируемом окружении.

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

Конечная точка projects для API аудита событий

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

Спасибо Julien Millau (@devnied) за этот вклад от сообщества!

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

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

Тренды и подробности в аналитике тикетов

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

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

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

Ограничение доступа на основе IP-адресов теперь в Premium

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

Ограничение доступа на основе IP-адресов теперь доступно для планов Premium и Silver. Эта фича позволяет вам ограничить доступ к группам и их контенту по одной или нескольким IP-подсетям. Включение ограничения доступа по IP гарантирует, что ваши данные не будут покидать пределы территории, не блокируя при этом доступ ко всему инстансу.

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

Заголовок тикета теперь зафиксирован на странице

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

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

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

Поддержка EditorConfig в Web IDE

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

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

При открытии файла Web IDE будет искать файл с именем .editorconfig в текущем каталоге и во всех родительских каталогах. Если такой файл будет найден и в нем есть настройки, соответствующие пути к открытому файлу, то эти настройки будут применены к нему. Web IDE обеспечивает поддержку большинства широко поддерживаемых функций EditorConfig, за исключением charset.

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

Скрытие вступительной части YAML в статическом редакторе сайтов

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

Статические генераторы сайтов используют первые несколько строк (вступительную часть, "front matter") в начале файла Markdown, между двумя строками ---, для форматирования, настройки или парсинга страницы. Вступительная часть не должна отображаться вместе с содержимым страницы и должна при этом соответствовать определенным правилам форматирования.

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

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

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

Вставка изображений в Markdown в Web IDE

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

При работе с Markdown-контентом в Web IDE часто требуется добавлять в него изображения. В большинстве редакторов это требует поиска нужного изображения, добавления его в файловую структуру и последующей ссылки на него с помощью синтаксиса Markdown.

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

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

Фильтр конвейеров по статусу и имени тега

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

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

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

Переменные CI/CD для инстансов

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

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

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

Шаблоны для упрощения первоначальной настройки ключевых слов

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

Понять, как использовать новое ключевое слово rules, может быть сложно, особенно если ранее вы пользовались только only/except. Эти два ключевых слова отличаются принципиально: rules создает конвейер мерж-реквеста по умолчанию, а only/except этого не делает.

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

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

Скачивайте артефакты заданий проще и быстрее

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

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

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

С GitLab 13.1 мы добавили поддержку скачивания следующих типов отдельных отчетов по артефактам:

• доступность
• архив
• cobertura
• качество кода
• сканирование контейнера
• dast
• сканирование зависимостей
• dotenv
• junit
• управление лицензиями
• сканирование лицензии
• lsif
• метрики
• производительность

Эта фича доступна для всех пользователей GitLab. Однако типы отчетов по артефактам отличаются для разных тарифов.

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

Экспорт списка уязвимостей с панелей безопасности группы

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

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

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

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

Более явный поиск секретных ключей и новый отдельный шаблон поиска секретных ключей

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

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

CI/CD конфигурация для поиска секретных ключей теперь предоставляется в отдельном шаблоне от GitLab и запускается как новый тип сканирования. Этот новый шаблон поиска секретных ключей теперь также включен в Auto DevOps. Мы рекомендуем вам использовать этот шаблон и затем убрать старое определение задания SAST secrets-sast из шаблона настройки SAST в файле SAST.gitlab-ci.yml. Мы сняли видео, которое объяснит вам процесс перехода на этот новый шаблон. Мы избавимся от старого определения SAST-задания по поиску секретных ключей в следующем релизе GitLab.

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

Сканирование SAST для Helm charts

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

Наш анализатор статического сканирования безопасности приложений (SAST) для манифестов Kubernetes теперь поддерживает Helm чарты. Это обновление также добавляет поддержку двух новых переменных окружения для точной настройки анализатора: KUBESEC_HELM_CHARTS_PATH и KUBESEC_HELM_OPTIONS.

Отдельное спасибо @agixid за вклад в разработку этой фичи!

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

Документация по сине-зеленым развертываниям

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

Мы задокументировали пример сине-зеленого развертывания с использованием NGINX, который загружает развертывание напрямую из файла .gitlab-ci.yml. Этот пример поможет вам настроить ваши сине-зеленые развертывания, если вы используете похожую конфигурацию, и предоставляет набор действий, которые вы можете применять и для других типов приложений.

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

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

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

Каждый раз, когда конвейер завершается с ошибкой, вы автоматически получаете уведомление по email. Однако, когда после неудачи конвейер восстанавливается и завершается успешно, автоматическое уведомление не приходит, что заставляет вас вручную проверять статус конвейера. В этом релизе мы рады представить вам фичу от @jacopo-beschi, которая решает эту проблему путем автоматической отправки уведомления, когда конвейер после неудачи завершается успешно.

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

Улучшенная авторизация для файла состояния Terraform под управлением GitLab

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

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

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

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

Назначение оповещений GitLab членам команды

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

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

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

Логирование назначений оповещений в системных заметках

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

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

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

Отправка оповещений GitLab в Slack

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

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

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

Создание списков To-Do при назначении работы по оповещениям

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

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

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

Отображение внешних ссылок на панели метрик

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

Панели метрик наиболее полезны тогда, когда они позволяют добавлять больше деталей. В GitLab 13.1 вы сможете добавлять ссылки в меню More actions на вашей панели метрик. Так вы можете связать вашу панель метрик и панель управления с другими панелями метрик и инструментами устранения неполадок, которыми пользуется ваша команда.

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

Поддержка UTC для панелей метрик

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

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

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

Панели задач с самомониторингом для пользователей Omnibus GitLab

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

В GitLab 13.1 пользователи Omnibus GitLab получат новую панель для проектов с самоуправлением. Эта панель управления будет работать из коробки и позволит проводить мониторинг состояния инстанса GitLab.

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

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

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

С первым релизом пользовательского интерфейса для управления правилами сетевой безопасности контейнеров пользователи смогут легко сканировать список правил, применяемых в их проекте, и включать/выключать эти правила через пользовательский интерфейс. Вы можете посмотреть на новое управление правилами в Security & Compliance -> Threat Management -> Policies.

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

Сократилось время поиска через API

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

Если вы когда-нибудь пользовались API для поиска, то могли заметить, что для некоторых поисков время ответа могло достигать более 11000 мс. Очевидно, что это не очень эффективно.

В GitLab 13.1 мы оптимизировали некоторые запросы, решив проблему N+1 вызовов базы данных, и увидели 40%-е улучшение времени ответа. Поиск еще никогда не был таким быстрым!

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

Поиск со страницы проекта через выпадающее меню включает поиск по группе

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

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

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

Исправленные баги

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)

Вот некоторые баги, которые мы исправили в релизе 13.1, и о которых стоит упомянуть:

• Наблюдения по релизу не собирались, если релиз был создан через пользовательский интерфейс
• Изображения в списке релизов выходили за рамки страницы
• Некорректно отображалась разметка в описании релиза
• Не было отображения ошибок нижестоящих конвейеров в вышестоящих
• Появлялась ошибка 404 Not Found при попытке скачать архив артефактов по определенному тегу через API заданий
• Не было проверки размера значения переменных инстанса
• Появлялось некорректное сообщение об ошибке, когда конвейеры отключены, а мерж-реквест должен завершиться успешно (must succeed) и нет запущенных внешних конвейеров
• API поиска игнорировал параметр ref при поиске коммитов
• Возникала ошибка настройки параметра Elasticsearch highlight.max_analyzed_offset в GitLab
• Была проблема со вложенными массивами в Elasticsearch версии 7.7.0
• Заметки в конфиденциальных тикетах отображались как конфиденциальные
• Не было отображения тикетов, добавленных в эпик через API на дереве эпиков
• Неправильно применялись ограничивающие (scoped) метки при добавлении по имени через API
• Оператор NOT игнорировался в булевом фильтре для эпиков

Все исправления багов в GitLab 13.1 можно посмотреть здесь.

Добавление события аудита при создании ключа SSH через API

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

Спасибо Rajendra Kadam (@raju249) за вклад в разработку этой фичи!

Теперь при создании для пользователя SSH-ключа через API самим пользователем или администратором, это действие будет залогировано в таблице событий аудита. Ранее эти действия не логировались, что создавало пробел в аудите учетных данных SSH для пользователя.

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

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

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

Аналитика вкладов в разработку помогает командам понимать, как нагрузка распределяется между участниками. Ранее вклад пользователей, подтверждающих мерж-реквесты (approvers) никак не учитывался, несмотря на их значимую роль в обеспечении необходимого ревью. Таблица со вкладами пользователей в группе теперь включает столбец Approved MRs, с возможностью сортировки по числу подтвержденных мерж-реквестов.

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

Членство в группе для пользователей с разными почтовыми доменами

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

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

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

Быстрое назначение исполнителей

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

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

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

Распределение операций чтения по кластеру Gitaly (бета)

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

Кластер Gitaly позволяет вам реплицировать репозитории Git на нескольких теплых нодах Gitaly, что повышает надежность путем устранения единичных точек отказа.

В GitLab 13.1 операции чтения Git можно распределять по актуальным репликам Gitaly. Это позволяет более эффективно использовать доступные ресурсы и может улучшить производительность.

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

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

Автоматическое аварийное переключение кластера Gitaly включено по умолчанию

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

Кластер Gitaly улучшает отказоустойчивость хранилища Git в GitLab: устраняет единичные точки отказа, обнаруживает сбои и автоматически переключается на реплику. Начиная с GitLab 13.1, когда Gitaly Cluster настроен, по умолчанию включаются выбор ноды-лидера для SQL и аварийное переключение.

Если во время аварийного переключения обнаруживаются нереплицированные операции записи, кластер переводится в режим только для чтения, чтобы предотвратить split brain (синдром расщепленного мозга). В будущем сильная согласованность потребует успешной операции записи на нескольких нодах Gitaly, прежде чем ответить сигналом об успехе, что предотвратит эту проблему и необходимость помечать кластер как доступный только для чтения.

Ранее в GitLab 13.0 вместо аварийного переключения по умолчанию был выбор лидера в памяти.

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

Добавление и предварительный просмотр изображений в редакторе статических сайтов

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

Редактор статических сайтов предоставляет немедленную визуальную обратную связь при написании контента в Markdown и интуитивно понятные элементы управления форматированием для обеспечения согласованной и точной разметки. Однако в GitLab 13.0 визуальное редактирование ограничивалось текстом.

В GitLab 13.1 вы можете быстро добавлять изображения на свои страницы с помощью редактора статических сайтов. После нажатия иконки Изображение на панели форматирования просто укажите URL, добавьте необязательный текст ALT, и все готово. Ссылка может вести на изображения, уже размещенные в вашем проекте, ресурс, размещенный в сети доставки контента (CDN), или любой другой внешний URL. Редактор создает миниатюры для предварительного просмотра, так что вы cможете убедиться, что добавили правильное изображение и нет ссылок на отсутствующие изображения.

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

Терминал Web IDE и синхронизация файлов перенесены в Core

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

GitLab 11.6 представил Веб-терминалы для Web IDE. Через несколько релизов была добавлена синхронизация файлов с веб-терминалом, позволяющая веб-терминалу взаимодействовать с изменениями, внесенными через Web IDE.

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

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

GitLab Runner 13.1

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

Мы также выпускаем обработчик заданий GitLab версии 13.1. GitLab Runner это легкий, масштабируемый агент, который запускает ваши сборочные задания и отправляет результаты обратно в инстанс GitLab. Обработчик заданий GitLab работает совместно с GitLab CI/CD, опенсорсной службой непрерывной интеграции, входящей в состав GitLab.

Что нового:

• Поддержка Windows 1903 для Docker executor под Windows
• Поддержка Windows 1909 для Docker executor под Windows
• Пакеты для RHEL/CentOS 8
• Выполняется любой шаг, определенный в ответе, возвращаемом заданием
• Kubernetes executor поддерживает конфигурацию авторизации Docker для приватных реестров

Исправления ошибок

• Cборка иногда получала ошибку нет такого файла или каталога при доступе к каталогу сборки
• Запущенные длительные задания были отменены в пользовательском интерфейсе GitLab, но обработчик заданий продолжал процесс
• Обработчики заданий могли не поддерживать связь с сервером GitLab при сборке задания
• Задание застревало со стратегией прикрепления на Kubernetes
• Kubernetes прикреплял недопустимую метку времени лога при парсинге логов
• Была проблема с Kubernetes, когда скрипт сборки генерировал длинную строку
• Терялся конец вывода из обработчика заданий
• Было невозможно публиковать вспомогательные образы для Windows

Список всех изменений находится в changelog GitLab Runner.

Документация по обработчику заданий GitLab.

Сначала выполняются тесты для измененных файлов

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

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

Разработчики Ruby могут сократить цикл обратной связи, используя gem TestFileFinder, чтобы найти тесты, предназначенные для измененного кода, а затем запустить эти тесты на ранней стадии в конвейере. Это подход MVC к решению проблемы, но мы надеемся, что он будет вам полезен. Мы с нетерпением ждем отзывов и идей в проекте TestFileFinder.

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

Используйте метаданные, чтобы понять, как создаются ваши пакеты NuGet

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

Когда пакет NuGet загружается в GitLab, задание открывает архив и читает файл .nuspec. Имя и версия пакета извлекаются сразу, но некоторые другие поля, например dependencies, project_url и tags, доступны, но не извлечены. Эти поля полезны для понимания того, как был построен пакет и каковы его зависимости.

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

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

Динамические значки состояния тикета на панелях безопасности

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

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

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

На панелях безопасности сохраняются фильтры

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

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

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

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

Анализатор SAST для Rails теперь доступен для всех

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

Мы хотим помочь разработчикам писать классный код и меньше беспокоиться о распространенных ошибках безопасности. Статическое тестирование безопасности приложений (SAST) помогает предотвратить уязвимости безопасности, позволяя разработчикам легко выявлять типичные проблемы безопасности по мере разработки кода и заранее их предотвращать. В рамках наших обязательств по управлению GitLab мы делаем наш анализатор SAST для Rails (Brakeman) доступным для каждого плана GitLab. Это позволит всем пользователям GitLab, работающим с Rails, использовать сканирования безопасности SAST для своих проектов. Мы продолжим переводить другие анализаторы SAST с открытым исходным кодом (OSS) в план Core. Вы можете следить за нашим эпиком SAST to Core, чтобы узнать, когда станут доступны другие анализаторы, и внести свой вклад в этот процесс.

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

Поддержка API для установки нескольких стратегий переключаемых фич

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

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

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

Встроенная ссылка на руководство по развертыванию в AWS

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

Настройка развертываний AWS не всегда так проста, как нам хотелось бы. Чтобы вам было проще использовать наши фичи AWS, мы добавляем ссылки на наши шаблоны и документацию AWS, когда вы начинаете добавлять переменные AWS CI/CD. Эти ссылки должны помочь вам быстрее начать работу.

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

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

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

Теперь GitLab позволяет вам удобно указать тип ссылки на ресурс, добавленный в ваш релиз, с помощью выпадающего меню. Ранее, если вы добавляли ссылки к релизу, вы не могли указать тип ресурса. Теперь вы можете выбрать тип ресурса из следующих вариантов: Runbook, Package, Image или Other.

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

Упрощенная настройка для интеграции Terraform

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

Вы можете проще запускать фичи Terraform, интегрированные в GitLab, с одним из образов Terraform, предоставленных GitLab. Образы Terraform в GitLab расширяют официальные образы Terraform для бета-версий Terraform 0.12 и 0.13, включая простые команды для использования виджетов для мерж-реквестов без раздувания ваших файлов YAML для CI/CD.

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

Сортировка столбцов для списка оповещений

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

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

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

Легенды в виде таблицы на панели метрик

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

Без соответствующего контекста график бывает сложно понять. В GitLab 13.1 мы упростили сравнение данных при просмотре графиков, добавив легенду графика в виде таблицы.

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

На панели метрик отображаются ссылки на связанные панели

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

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

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

Проверка конфигурации панели метрик

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

Настраивать файлы YAML для панели мониторинга может быть сложно. GitLab 13.1 добавляет проверку в файл YAML, чтобы помочь вам диагностировать проблемы с панелью метрик. Если YAML определение панели мониторинга ошибочно, появится предупреждающее сообщение.

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

На страницах статуса теперь показываются изображения

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

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

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

Улучшения в GitLab Helm chart

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

• Шаблон extraEnv теперь поддерживается в GitLab Helm charts. Это позволяет вам предоставлять дополнительные переменные окружения, такие как прокси-серверы, как для определенных чартов GitLab, так и глобально для всех чартов. Обратитесь к документации по глобальным настройкам или документации по подчартам, чтобы подробно узнать, как реализовать extraEnv.
• Пользовательские аннотации, определенные в разделе deployment глобальных настроек в values.yml, теперь доступны во всех подчартах GitLab. Аннотации развертывания позволяют предоставлять доступ на уровне развертывания, а не на уровне ноды, например разрешая развертыванию читать из корзины Amazon S3, не давая всей ноде доступа к этой корзине. Подробнее о настройке аннотаций развертывания смотрите в документации по аннотациям.
• Библиотеки PostgreSQL и клиент в образах контейнера GitLab обновились до PostgreSQL 12, что позволяет использовать больше версий PostgreSQL. Обратите внимание, что GitLab 13.1 по-прежнему поддерживает только PostgreSQL 11, но поддержка PostgreSQL 12 планируется в будущем релизе.
• Для повышения безопасности теперь вы можете передать ключ-секрет Kubernetes для значений заголовков с высокими требованиями к безопасности, таких как токен авторизации для конечных точек при настройке уведомлений реестра. За информацией о настройке обращайтесь к документации по настройкам реестра.

Документация по GitLab Chart.

Новая команда аварийного восстановления Geo для проверки перед аварийным переключением

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

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

В GitLab 13.1 добавлена команда Geo gitlab-ctl promotion-preflight-checks, которая перечисляет все необходимые предполетные проверки и требует от системных администраторов подтверждения, что все эти проверки выполнены. Команда автоматически запускается при запуске
gitlab-ctl promote-to-primary-node.

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

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

Уменьшен размер индекса для расширенного глобального поиска

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

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

Мы отключили частичное совпадение при поиске по коду в GitLab 13.1, что привело к уменьшению размера индекса на 75%. Если вам нужно частичное совпадение, вы можете использовать подстановочные знаки в своем поисковом запросе. Частичное совпадение для других типов контента, таких как тикеты или мерж-реквесты, по-прежнему поддерживается.

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

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

Используйте роли IAM для зашифрованных корзин Amazon S3

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

Теперь вы можете использовать роли AWS IAM для доступа к зашифрованным корзинам S3. Ранее такие корзины не работали вообще. Чтобы узнать больше, смотрите документацию по хранилищу объектов.

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

---

Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 13.1 released with Alert Management and Code Quality Enhancements.

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

Ну и год же был 2020! Мы счастливы представить релиз 13.7 с более чем 45 фичами и улучшениями поставки ПО, вышедший как раз к праздникам.

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

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

Вот что вас ждёт в релизе 13.7:

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

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

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

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

Улучшена автоматизация релизов и гибкость развёртывания

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

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

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

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

Более надёжное и эффективное управление пакетами и зависимостями

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

Мы также внесли улучшения в прокси зависимостей от GitLab; кстати, эта фича была перенесена в Core в GitLab 13.6.

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

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

И, наконец, вы можете использовать предопределённые переменные с прокси зависимостей взамен того, чтобы полагаться на свои собственные определённые переменные или вшитые значения в вашем файле gitlab.ci-yml. Таким образом, появился более масштабируемый и эффективный способ начать проксирование и кэширование образов.

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

Взгляните на ещё несколько классных новых фич релиза 13.7:

• Импорт требований из CSV-файла
• Размещение пользователей с помощью SAML на GitLab.com
• Возможность задавать через интерфейс процент трафика канареечных развёртываний
• Просмотр частоты развёртываний через API

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

6-7го января у нас прошёл виртуальный хакатон, узнайте больше об этом и будущих мероприятиях от GitLab здесь.

MVP этого месяца Rachel Gottesman

Rachel активно помогала нашей команде технических писателей внедрить согласованный стиль в документации для исправления использования будущего времени в наших документах. В релизе 13.7 Rachel открыла 33 мерж-реквеста, чем помогла нашей команде справиться с этой важной и кропотливой задачей. Спасибо, Rachel!

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

Проверяющие для мерж-реквестов

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

Попросить коллегу просмотреть ваш код должно быть обычной частью рабочего процесса, но иногда это бывает неоправданно сложно. Такая простая задача, как запрос на ревью, может привести к путанице. Например, как именно следует запрашивать: через электронное письмо, комментарий, сообщение в чате? Без формального механизма ревью мерж-реквестов могут быть непоследовательными, и за их проведением будет сложно уследить. Раньше уже можно было назначить проверяющего на мерж-реквест, но и автор, и рецензент отображались в одном и том же поле Assignee, что не позволяло другим членам команды узнать, кто за что отвечал в этом мерж-реквесте.

GitLab 13.7 представляет новую фичу теперь авторы мерж-реквеста могут запросить ревью у конкретных пользователей. В новом поле Reviewers пользователи могут быть назначены проверяющими для мерж-реквеста аналогичным образом, как назначаются ответственные (assignee). Назначенные на ревью пользователи получат уведомление, предлагающее им просмотреть мерж-реквест. Таким образом, теперь существует формальный процесс запроса ревью для мерж-реквеста и уточняются роли каждого пользователя в работе над ним.

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

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

Автоматический откат в случае сбоя

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

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

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

Клонирование тикета через быстрое действие

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

Чтобы сделать создание похожих тикетов более эффективным, тикеты теперь поддерживают быстрое действие /clone, которое создаёт в том же проекте новый тикет с идентичными названием, описанием и метаданными. Быстрое действие /clone заменяет более трудоёмкий процесс, который включал в себя несколько шагов для создания тикета, копирования идентификатора или пути к исходному тикету и использование быстрого действия copy_meta.

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

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

Обработчик заданий GitLab для Red Hat OpenShift

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

Наконец-то стал доступен образ контейнера обработчика заданий GitLab (GitLab runner) для платформы контейнеров Red Hat OpenShift! Чтобы установить обработчик заданий на OpenShift, воспользуйтесь новым оператором обработчиков заданий GitLab. Он доступен на бета-канале в Red Hat's Operator Hub веб-консоли для администраторов кластеров OpenShift, уже развёрнутой по умолчанию на платформе, где они могут найти и выбрать операторы для установки на своём кластере. На платформе контейнеров OpenShift Operator Hub уже развёрнут по умолчанию. Мы планируем перенести оператор обработчика заданий GitLab на стабильный канал, а в начале 2021 года в общий доступ. Наконец, мы также разрабатываем оператор для GitLab, так что следите за будущими публикациями.

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

Просмотр статуса развёртываний на странице окружений

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

Ранее на странице окружений не было никакого способа узнать о том, что сейчас выполняется развёртывание. Теперь на этой странице отображаются статусы развёртываний и предупреждения, благодаря чему вы можете принять решение о том, какие действия нужно предпринять, основываясь на статусе развёртывания (успешное, неудачное или текущее). Например, можно остановить текущее развёртывание или откатить завершённое.

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

Задавайте через пользовательский интерфейс процент трафика для канареечного развёртывания

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

В GitLab 13.7 вы можете менять процент трафика для канареечного развёртывания (значение canary-weight) непосредственно с досок развёртывания в пользовательском интерфейсе. Вы также можете менять это значение из gitlab-ci.yml и через API, но сделав это в пользовательском интерфейсе, вы сможете наблюдать за развёртыванием и при необходимости отмасштабировать поды прямо с досок развёртывания. Так у вас будет больше контроля над ручными или инкрементальными развёртываниями по таймеру, а также вы сможете лучше контролировать и даже снижать риски.

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

Просмотр частоты развёртываний через API

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

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

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

Поддержка нескольких файлов манифеста в проекте

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

В предыдущих релизах для использования нашего агента для Kubernetes (GitLab Kubernetes Agent) требовалось, чтобы пользователи собирали все ресурсы Kubernetes в один файл манифеста. Теперь же агент может собирать манифесты Kubernetes рекурсивно из указанных каталогов в вашем проекте. Ваши специалисты по платформе теперь смогут использовать один репозиторий для управления различными кластерами из единого места, а также описывать крупные развёртывания с помощью одного агента.

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

Импорт требований из внешних инструментов

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

Для эффективной совместной работы очень важно, чтобы все ваши требования хранились в одном месте, поэтому мы рады сообщить, что теперь вы можете импортировать требования из CSV-файлов!

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

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

Несколько конечных точек HTTP для оповещений

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

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

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

Синхронизация групп на GitLab.com с помощью SAML

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

В GitLab 13.7 вы можете привязать группу в вашем поставщике учётных записей к группе на GitLab.com с помощью SAML. Членство в группе будет обновляться, когда пользователь войдёт в учётную запись GitLab через своего провайдера SAML. Эта фича снижает необходимость в ручном назначении групп, что снижает загрузку по группам для администраторов GitLab. Синхронизация групп также улучшает адаптацию новых членов групп, избавляя их от необходимости запрашивать доступ у администраторов групп GitLab.

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

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

DevOps Adoption

(ULTIMATE) Стадия цикла DevOps: Manage

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

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

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

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

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

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

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

Ограничение создания проектов и групп для внешних аккаунтов

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

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

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

Сортировка по числу блокируемых тикетов

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

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

Ранее в списке тикетов было невозможно посмотреть, какие из тикетов блокируют другие. Единственный способ это сделать это открыть каждый из них и просмотреть список блокируемых тикетов под описанием тикета, что занимает очень много времени.

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

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

Просмотр файлов в мерж-реквестах по одному

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

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

В GitLab 13.7 мы добавили возможность просматривать файлы по одному при просмотре мерж-реквеста. При переходе на вкладку мерж-реквеста Изменения кликните на иконку с шестерёнками и поставьте галочку Показывать файлы по одному. После выбора этого параметра вы сможете просматривать файлы по одному, переключаясь между ними при помощи кнопок Предыдущий и Следующий.

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

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

Просмотр изменений мерж-реквеста в VS Code

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

При ревью мерж-реквестов в VS Code для обращения к изменениям зачастую приходится делать checkout ветки и затем пытаться разобраться в диффе между этой веткой и целевой веткой мержа.

С релизом 3.7.0 расширения GitLab Workflow изменения мерж-реквеста стали доступны напрямую в VS Code. Это позволяет быстро просматривать изменения в мерж-реквестах ваших проектов.

В рамках работы над добавлением полноценного ревью кода в VS Code следующим шагом мы собираемся добавить комментарии к диффам.

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

Улучшенное скачивание артефактов для вложенных конвейеров

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

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

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

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

Обход ограничений Docker и ускорение конвейеров

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package
Для более быстрых и надёжных сборок вы можете использовать нашу фичу, прокси зависимостей, для кэширования образов контейнеров из Docker Hub. Однако, когда Docker начал применять ограничения по количеству запросов docker pull, вы могли заметить, что даже когда ваш образ скачивался из кэша, Docker всё равно засчитывал его в лимит. Это происходило потому, что прокси зависимостей кэшировал только слои (или блоб-объекты) образа, но не манифест, который содержит информацию о том, как собрать данный образ. Так как манифест был необходим для сборки, всё равно приходилось выполнять pull. А если Docker Hub был недоступен, вы не могли скачать нужный образ.
Начиная с этого релиза прокси зависимостей будет кэшировать и слои, и манифест образа. Так что при первом скачивании с использованием alpine:latest образ будет добавлен в кэш прокси зависимостей, и это будет считаться за один pull. В следующий раз, когда вы будете скачивать alpine:latest, всё будет скачиваться из кэша, даже если Docker Hub недоступен, и это скачивание не будет учитываться в лимите Docker.

Напоминаем вам, что начиная с 13.6 прокси зависимостей стал доступен в плане Core. Поэтому попробуйте эту фичу сейчас и скажите нам, что вы о ней думаете. Или даже лучше, помогите нам с открытыми тикетами.

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

Быстрый поиск и просмотр общих пакетов

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

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

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

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

Прокси зависимостей для приватных проектов

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

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

Теперь вы можете использовать прокси зависимостей и для приватных проектов. Вы можете снизить свои скачивания с Docker Hub путём кэширования ваших образов контейнера для использования их в будущем. Так как прокси зависимостей хранит образы Docker в пространстве, связанном с вашей группой, вы должны авторизоваться с вашим логином и паролем GitLab или с личным токеном доступа, для которого есть разрешение как минимум на чтение (read_registry).

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

Улучшенная поддержка анализаторов SAST для нескольких проектов

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

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

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

Описание релиза во внешнем файле

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

Если вы создаёте релизы в конвейерах через файл .gitlab-ci.yml вашего проекта, вам, возможно, было сложно поддерживать в актуальном состоянии описание каждого релиза. В релизе GitLab 13.7 вы можете задавать описание вашего релиза в файле с контролем версий или в автоматически генерируемом файле и вызывать его из .gitlab-ci.yml. При этом содержимое файла загружается в описание релиза в формате Markdown. Это упрощает создание, поддержку и использование контроля версий для релизов, а также будет особенно полезно при автогенерации лога изменений. Огромное спасибо Nejc Habjan и Siemens за этот невероятный вклад!

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

Поддержка для версий Kubernetes 1.17, 1.18 и 1.19

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

Поддержка GitLab для последних версий Kubernetes позволяет вам пользоваться преимуществами интеграций GitLab с Kubernetes, такими как GitLab Kubernetes Agent, Auto DevOps и на более поздних кластерах GitLab Managed Apps. В этом релизе GitLab добавил официальную поддержку для версий Kubernetes 1.17, 1.18 и 1.19.

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

Geo поддерживает репликацию сниппетов

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

Geo теперь поддерживает репликацию сниппетов под контролем версий на вторичные ноды, что позволит распределённым командам получать доступ к ним с ближайшей ноды Geo, что снижает задержку и делает весь процесс удобнее. Кроме того, эти данные могут быть восстановлены со вторичной ноды при переключении на неё в случае сбоя.

В данный момент мы не поддерживаем верификацию для этого типа данных, но мы планируем добавить её в будущем.

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

Поддержка зашифрованных учётных данных LDAP

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

GitLab использует единый файл конфигурации, например gitlab.rb в Omnibus GitLab, что упрощает настройку всех связанных сервисов. В этот файл конфигурации включены некоторые секретные ключи, например учётные данные для аутентификации на сервере LDAP. Хотя для доступа к этому файлу требуются специальные права, хорошей практикой считается отделять секретные ключи от конфигурации.

Установки Omnibus GitLab и Source теперь поддерживают зашифрованные учётные данные, причём первыми поддерживаемыми учётными данными стали LDAP. Это снижает уязвимость конфигурационного файла GitLab, а также помогает достичь соответствия требованиям заказчика.

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

Веб-хуки при добавлении новых участников группы

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

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

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

Улучшенная фильтрация и сортировка списков участников группы

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

Мы продолжили улучшать наш список участников группы и добавили для него новые возможности фильтрации и сортировки. Это поможет администраторам группы быстро находить нужную им информацию. Например, сортировку по последнему времени входа (Last sign-in) можно использовать для поиска пользователей, которые в последнее время не заходили на GitLab, и для помощи в управлении лицензиями.

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

Автоматическая подготовка профиля пользователя с SAML

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

Раньше в качестве одной из частей включения в группу с SAML пользователям нужно было заполнять форму регистрации. В GitLab 13.7 мы представляем синхронизацию пользователей для групп с использованием SAML. Когда пользователь в первый раз входит в группу с SAML, учётная запись пользователя создаётся для него автоматически, если нет существующего пользователя с таким же адресом электронной почты. Автоматическая подготовка с SAML улучшает процесс адаптации новых пользователей и гарантирует, что вновь созданные учётные записи содержат правильную информацию.

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

Настраиваемый адрес электронной почты для службы поддержки

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

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

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

Различайте изменения форматирования и правки, сделанные из редактора статических сайтов

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

Редактор статических сайтов предлагает интуитивно понятный и знакомый всем режим редактирования WYSIWYG для контента Markdown. Чтобы обеспечить единообразный формат вывода Markdown, редактор WYSIWYG автоматически переформатирует содержимое страницы в соответствии с соглашениями о стилях, определёнными в парсере Markdown. Это происходит полностью в фоновом режиме ещё до того, как вы начнёте редактировать. Однако эти изменения форматирования коммитятся вместе с вашими изменениями содержимого. Если страница, которую вы редактируете, не следовала тем же соглашениям о стилях, для проверяющих итогового мерж-реквеста может быть сложно отличить ваши изменения от автоматического форматирования.

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

В будущем мы планируем сделать параметры форматирования настраиваемыми, так что следите за новостями в соответствующем тикете.

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

Предзаполненные переменные при ручном запуске конвейеров

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

Раньше, когда вы хотели запустить конвейер вручную, вам нужно было узнать нужные переменные, а затем ввести их на странице Запуск конвейера (Run Pipeline). Это может быть утомительно и чревато ошибками, если нужно ввести множество пар ключ-значение. Теперь форма для запуска конвейера будет сгенерирована для вашего конвейера с переменными, предварительно заполненными на основе определений переменных в вашем файле .gitlab-ci.yml, что сделает этот процесс более эффективным.

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

Собранные с помощью CI/CD пакеты всегда отображают информацию о сборке

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

Если вы публиковали пакеты в реестре пакетов, то могли заметить, что пакеты, созданные с помощью GitLab CI/CD, не всегда отображали коммит и конвейер, ответственные за создание или обновление вашего пакета. Это могло происходить по нескольким причинам.

Во-первых, возможно, мы ещё не поддерживали эту функцию, как в случае с Composer и Conan. Во-вторых, проблема возникала у тех из вас, кто обновлял одну и ту же версию пакета из разных веток или коммитов. Однако до недавнего времени пользовательский интерфейс отображал только первое развёртывание без каких-либо обновлений. Кроме того, на странице подробных сведений отображается ветка, в которой был создан пакет, а не самый последний коммит. В результате вам приходилось искать эту информацию, просматривая историю коммитов, что было не очень эффективно.

В дальнейшем любой пакет, собранный или обновлённый с помощью GitLab CI/CD, будет отображать информацию о коммите и конвейере в пользовательском интерфейсе пакетов. Чтобы избежать проблем с производительностью или пользовательским интерфейсом, будут отображаться только пять обновлений пакета. В майлстоуне 13.8 мы создадим дизайн, который поможет вам легко просматривать все данные, включая историю. А пока вы можете использовать API пакетов, чтобы смотреть всю историю сборки данного пакета.

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

Используйте предопределённые переменные с прокси зависимостей

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

С помощью проксирования и кэширования образов контейнеров из Docker Hub прокси зависимостей помогает вам повысить производительность ваших конвейеров. Несмотря на то, что прокси-сервер предназначен для интенсивного использования с CI/CD, для использования этой фичи вам нужно было определить свои собственные переменные или прописать значения в вашем файле gitlab.ci-yml. Это затрудняло начало работы для тех, кто работает один, и не позволяло использовать его в качестве масштабируемого решения, особенно для организаций с множеством различных групп и проектов.

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

• CI_DEPENDENCY_PROXY_USER: пользователь CI для входа в прокси зависимостей,
• CI_DEPENDENCY_PROXY_PASSWORD: пароль для входа в прокси зависимостей,
• CI_DEPENDENCY_PROXY_SERVER: сервер для входа в прокси зависимостей,
• CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX: префикс образа для извлечения образов через прокси зависимостей.

Попробуйте и дайте нам знать, что вы думаете!

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

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

(CORE, STARTER, PREMIUM, FREE, BRONZE, SILVER) Стадия цикла DevOps: Secure

С помощью SAST и поиска секретных ключей, которые теперь доступны для всех пользователей, мы упростили жизнь всем пользователям GitLab, взаимодействующим с результатами сканирования безопасности в мерж-реквесте, за счёт облегчения доступа к результатам сканирования безопасности. Ранее результаты сканирования безопасности были доступны только на странице Обзор конвейера, и вы должны были знать, где искать, чтобы найти их там. Теперь все мерж-реквесты будут показывать, были ли для них запущены проверки безопасности, и помогут вам найти артефакты задания. Это изменение не затрагивает работу с мерж-реквестами для пользователей плана Ultimate.

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

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

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

Мы ввели уязвимости как полноценные объекты в 12.10. Будучи объектом, каждая из них имеет уникальный URL-адрес, позволяющий напрямую перейти к деталям любой уязвимости. Несмотря на значительное улучшение видимости и согласованности, ссылки на уязвимости в тикетах и эпиках (в русской локализации GitLab цели) всё равно нужно копировать вручную в виде ссылок Markdown. Это делает неэффективным совместное использование, а ссылки на уязвимости в других областях GitLab более громоздкими, чем для других объектов, например тикетов.

Теперь на уязвимости можно ссылаться с помощью специальных ссылок. На них впервые будет опробован новый синтаксис [object_type:ID], который в конечном итоге распространится на другие существующие ссылки. Теперь вы можете быстро вставить ссылку на уязвимость из любого места, где обычно используется специальная ссылка, например из описания тикета или мерж-реквеста. Просто введите [vulnerability:123] в описании тикета, чтобы вставить ссылку на уязвимость с идентификатором 123 в том же проекте. Вы также можете добавить к идентификатору префикс пространства имён или проекта, чтобы ссылаться на уязвимости вне контекста текущего проекта.

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

Смотрите, какие коммиты и конвейеры выполняются в форке, а какие в родительском проекте

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

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

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

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

Запросы к базе данных выполняются быстрее при использовании балансировщика нагрузки

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

Многие запросы к базе данных повторяются несколько раз, так что их можно кэшировать для повышения общей производительности. Для GitLab можно кэшировать примерно 10% всех запросов. В GitLab 13.7 мы включили кэширование запросов к базе данных, когда используется балансировка нагрузки базы данных. На GitLab.com это приводит к кэшированию ~700 000 запросов каждую минуту и сокращает среднее время выполнения запросов вплоть до 10%.

Для запросов, которые выполняются более 100 раз, мы уменьшили продолжительность запроса на 11-31% и кэшировали ~30% всех операторов SELECT, которые бы в противном случае выполнялись на реплике базы данных.

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

Для новых установок по умолчанию используется PostgreSQL 12

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

Начиная с GitLab 13.3 PostgreSQL 12 был доступен в качестве опции как для пакетов Omnibus, так и для нашего Helm chart. PostgreSQL 12 улучшает производительность, а также предлагает значительные преимущества при индексировании и секционировании.

Начиная с GitLab 13.7 новые установки GitLab будут по умолчанию использовать PostgreSQL 12. Чтобы выполнить обновление вручную, запустите gitlab-ctl pg-upgrade.

Многонодовые инстансы базы данных должны будут переключиться с repmgr на Patroni до обновления с помощью Patroni. Затем можно обновить и повторно синхронизировать вторичные ноды Geo.

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

---

Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте: GitLab 13.7 released with merge request reviewers and automatic rollback upon failure.

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

Профессиональных секретов и инструментов достаточно у любого системного администратора или инженера. Сегодня мы расскажем об одном крайне полезном девайсе, Zalman ZM-VE500, которым пользуются системные инженеры дата-центров Selectel.

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

Что оставалось за кадром

Прежде всего надо было понять, достаточно ли будет возможностей автоматического установщика ОС для выполнения пожеланий пользователя. Если нужна была стандартная дисковая разметка и файловые системы, то использовался автоматический способ.

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

До массового появления серверов с UEFI проблема загрузки стояла особенно остро. Далеко не все серверы оснащались оптическим дисководом, а самым идеальным вариантом для Legacy-загрузки всегда был запуск с CD или DVD-диска. Очевидным способом было каждый раз подключать внешний привод и записывать диск. Но он имел один существенный недостаток: это долго и не всегда успешно. А если образ превышал по размеру стандартную DVD-болванку, то задача и вовсе становилась нетривиальной.

Разумеется, можно каждый раз записывать образ на флешку и загружаться с нее. Но этот метод имел несколько серьезных недостатков. Главным недостатком было то, что для разных дистрибутивов требовались разные утилиты для записи. Какого-либо универсального способа просто не существует. Так, например, для записи дистрибутива с Windows Server лучше всего использовать Rufus в режиме записи ISO, а для Ubuntu подойдет и обычный Win32 Disk Imager. Когда имеешь дело с зоопарком серверного и десктопного железа, нет никакой гарантии, что метод с записью на флешку сработает именно так, как задумано.

Эмуляция привода

Что если нам заставить жесткий диск представляться как CD/DVD-привод, а ISO-образы монтировать как диски? Примерно так и подумали инженеры Zalman, после чего на свет появилась линейка устройств ZM-VE*, имеющих возможность эмулировать оптический привод.

^{Слева ZM-VE500, справа ZM-VE300}
Использовать эти устройства очень просто, везде одна и та же логика работы:

1. Ставим внутрь любой отформатированный в NTFS жесткий диск или SSD.
2. Переключаем устройство в режим HDD.
3. В корне создаем папку _ISO.
4. Закидываем образы в созданную папку.
5. Переключаем устройство в режим VCD.
6. Подключаемся к нужному компьютеру или серверу.
7. Выбираем образ и монтируем его с помощью кнопки Mount.
8. ...
9. Профит!

^{Zalman ZM-VE500 с установленным 2.5 HDD}
Большинство ноутбуков, компьютеров и серверов опознают Zalman в качестве оптического привода, подключенного по USB, и корректно загружаются с этого устройства.

Особенности использования

Как говорилось в известном анекдоте, Но! Есть один нюанс.... А именно некоторые моменты, которые важно знать перед покупкой и использованием этого девайса. Первый потребление тока. Не все USB-порты обладают возможностью запитать устройство корректно, особенно на некоторых старых серверах. В этом случае поможет отдельно запитанный от розетки USB-хаб. Это, пожалуй, самое большое неудобство, замеченное при постоянной экcплуатации в условиях дата-центра.

Второй момент время инициализации и сброс USB-питания. Некоторые серверные платформы в процессе запуска иногда сбрасывают питание USB, что полностью гасит Zalman и заставляет его повторно инициализироваться. Порой бывает так, что платформа проходит POST-тесты быстрее, чем инициализируется Zalman. Вкупе с автоматической сменой загрузочного устройства в BIOS это вызывает крайне негативные эмоции.

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

Остальные особенности четко прописаны в инструкции по эксплуатации и не должны вызывать дополнительных вопросов. Так, к примеру, есть ограничение на количество ISO-образов. ZM-VE500, равно как и предыдущие устройства этой линейки, поддерживают только 32 образа внутри директории _ISO.

Оригинал или копия

Этот вопрос для меня остается открытым. Все дело в том, что существует такой производитель, как IODD. Он выпускает аналогичные контейнеры для дисков с такими же возможностями по эмуляции оптического дисковода.

^{IODD-2541 весьма схож с ZALMAN ZM-VE300. Источник фото.}
Кто-то говорит, что Zalman всего лишь перелицованная копия устройств IODD с измененной прошивкой. Другие утверждают, что IODD детально скопировал разработку Zalman. Из различных отзывов можно сделать вывод, что IODD работает стабильнее, поддерживает большее количество языков в меню и функций, но нам эти устройства использовать не доводилось.

На многих ресурсах сообщается, что некоторые модели Zalman, а именно ZM-VE200, 300 и 400, могут быть прошиты прошивкой от IODD и наоборот. Модели же 350 и 500 собственная разработка Zalman, и прошить их можно только оригинальными прошивками.

Вместо заключения

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

Надежны ли эти устройства Zalman? На мой взгляд, да, так как в условиях постоянного использования ZM-VE300 прожил более 5 лет и только потом вышел из строя. Стоит ли девайс своих денег? Однозначно ответ положительный.

Расскажите о своем опыте использования таких устройств.
Ждем вас в комментариях!

Технологии записи на оптические диски были мейнстримом достаточно долго и породили множество сопутствующих технологий, в том числе LightScribe и LabelFlash. Указать на диске его содержимое? Нарисовать картинку и затем выжечь ее лазером? Нет проблем. А сейчас расскажу, как это сделать. Вернее, как это было сделано эти технологии существуют много лет и жаль, что оптические диски сейчас редкость

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

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

С развитием технологий струйной печати стало возможным печатать изображения прямо на специальной поверхности дисков (printable-болванки). Многие струйные принтеры, даже выпускающиеся в 2020 году, позволяют печатать на дисках, а производители болванок продолжают выпускать соответствующие чистые диски. Казалось бы, вот он, идеальный способ маркировки. Но нет, производители оптических приводов разработали несколько технологий, позволяющих маркировать диски сразу в приводе, без необходимости использовать принтеры.

LightScribe

2004 год был богат на события: марсоход Spirit (MER-A) успешно спустился на поверхность Марса, киберспорт был признан в России официальным видом спорта, а Google запустил свой почтовый сервис Gmail. В этом же году две компании Hewlett-Packard и Lite-On создали технологию LightScribe, позволяющую наносить изображение на обратную сторону поверхности специально подготовленных дисков приводами с поддержкой этой технологии.

^{Диск Lightscribe с логотипом Wikipedia. Источник}

Болванки с поддержкой LightScribe на обратной стороне содержали специальный слой под поверхностью диска, темнеющий под воздействием ИК-лазера с длиной волны 780 нм. Помимо этого, на окантовке центрального отверстия диска была специальная разметка, позволяющая точно позиционировать диск в процессе прожига изображения.

Несмотря на то, что стереть изображение после нанесения нельзя разметка делала возможным безопасно маркировать диск повторно, добавляя новые элементы и надписи. Это удобно для мультисессионных дисков, записываемых методом TAO (Track-At-Once). Дописав на диск новые данные, можно дополнить и содержимое на обратной стороне, без риска испортить картинку.

До 2011 года компания HP старалась сделать эту технологию популярной, включая приводы с поддержкой LightScribe в свои ноутбуки. Диски для записи с поддержкой этой технологии выпускали все крупнейшие производители оптических дисков: BenQ, Imation, Memorex, Philips, Verbatim и сама HP. К сожалению, технология не была лишена недостатков, а для обычных пользователей была слишком сложна.

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

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

Из наиболее интересных примеров применения: 7 лет назад здесь, на Хабре, была крайне любопытная статья о создании гибких графеновых суперконденсаторов с помощью LightScribe. Нанесенный на диск оксид графита под действием лазерного излучения превращался в токопроводящий графен, что позволяло создавать готовые гибкие обкладки будущего ионистора.

^{Графеновые обкладки, созданные приводом с технологией LightScribe. Источник}

LabelFlash и DiscT@2

Уже на следующий год, после появления LightScribe, японская компания NEC представила свой вариант технологии нанесения изображений на оптические диски LabelFlash. На самом деле под этим названием кроется аж две разных технологии. Первая и основная, собственно LabelFlash, использует схожий с LightScribe принцип формирования изображения. Специальный слой на диске и привод с поддержкой технологии. Отличалась лишь длина волны лазера 655 нм, более высокое разрешение картинки (до 1000 dpi) и специфичный синий цвет болванок.

^{Диск LabelFlash с изображением Большого Красного Пятна на Юпитере. Источник}

Вторая технология это технология нанесения изображения не на обратную, а на рабочую поверхность диска. Впервые эта технология предназначалась для CD-R дисков и носила название DiscT@2 (Disk Tattoo). Была разработана и запатентована компанией Yamaha в 2001 году, а впоследствие продана и доделана для поддержки DVDR. Так что приводы, имеющие маркировку LabelFlash, могут нанести рисунок на рабочую сторону самой обычной DVDR болванки, теряя при этом полезную емкость диска. DiscT@2 чтобы не испортить полезные данные требует, чтобы диск был предварительно финализирован. Это самый простой способ промаркировать диск после записи, не вынимая его из привода.

Разумеется, качество татуирования диска при помощи DiscT@2 весьма невысокое изображение будет видно только под определенным углом. Несмотря на спецификацию, где говорится о 256 оттенках серого, мне не удалось их различить при нанесении на рабочую сторону диска. Хорошо видно только те рисунки и надписи, которые сделаны сплошным цветом без полутонов.

Ниже три фотографии, сделанные при помощи микроскопа МБС-10. Надпись была сделана на рабочей поверхности DVD-диска с максимально возможной скоростью с наилучшим качеством (технология DiscT@2). Поскольку до меня еще не доехал переходник, фотографировать пришлось прямо через окуляр, так что не судите строго за качество. Для повышения контраста фотографии были сделаны черно-белыми.


При увеличении хорошо видно, что прожиг ведется концентрическими кругами.


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


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

Диски LightScribe и LabelFlash, несмотря на схожесть технологии, между собой не совместимы. Сайты обеих технологий давно мертвы, но найти софт на просторах интернета не составляет особого труда. Такой комбайн, как Nero 7 в версии Premium, умеет обращаться с этими технологиями и легко позволяет вывести любое изображение на диск, поддерживая большое количество графических форматов.

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

Вместо заключения

Какой вывод я для себя сделал: все эти технологии были очень интересны для своего времени, но большинство пользователей не были готовы переплачивать за расходники и вообще вряд ли понимали, что означает надпись LightScribe или LabelFlash на приводе. О существовании DiscT@2 знало слишком мало людей, по крайней мере в России.

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

И тем не менее недавно вышедшая консоль PlayStation 5 представлена в двух версиях с приводом и без. Поэтому говорить об окончательной смерти оптических носителей рано. Возможно, нас ждет новая революция и оптические диски, вмещающие более 10 ТБ данных, но уверенности в этом нет.