В GitLab 11.1 мы улучшили отображение безопасности за счёт панелей, усовершенствовали поиск по коду для своевременного получения нужной информации, внесли изменения в UX и многое другое.
GitLab создан для совместной работы. Миссия GitLab в том, чтобы каждый мог вносить свой вклад, поэтому мы создали инструмент, который позволяет специалистам по управлению продуктом, разработке, тестированию, эксплуатации и информационной безопасности работать вместе. Именно поэтому мы встраиваем и разработку ПО, и DevOps в одно приложение. И считаем, что мерж-реквест – один из мощнейших инструментов для совместной работы.
Но иногда мерж-реквест — это не совсем то, что нужно.
Мерж-реквесты хороши тогда, когда нужно посмотреть, как отдельные изменения влияют на приложение. Но что если нужен более высокий уровень представления? Иногда необходимо посмотреть все текущие проблемы безопасности, которые влияют на ветку в целом. Новая панель управления безопасностью позволяет это сделать. В панели можно расставить приоритеты, чтобы сконцентрироваться на наиболее важных уязвимостях. Теперь нет необходимости сверять отчеты по всем мерж-реквестам — всё в одном месте. Мы думаем, что это будет особенно полезно тем, кто отвечает за информационную безопасность. Теперь в GitLab есть специальный инструмент, помогающий им выполнять свою работу. Работа с панелью управления безопасностью позволяет командам безопасности управлять приоритетом критически уязвимых мест, устранять одни и пропускать другие (когда они несущественны для данного проекта) так, чтобы при понижении приоритета они не повторялись в отчетах.
Надежный поиск по коду — одна из основных ценностей для разработчика. Если вы новый разработчик в команде, или если вы пытаетесь разобраться в большом количестве предыдущего кода перед тем, как добавить новую фичу, поиск — это хороший способ познакомиться с ключевыми областями.
Поиск по коду был доступен и раньше, но мы сделали его лучше. Расширенный синтаксис поиска позволяет ускорить поиск нужных файлов за счёт возможности отфильтровать по имени файла, пути к нему и его расширению.
Помимо новых функций безопасности, мы также улучшили UX: переделали виджет мерж-реквеста, добавили панель мерж-реквеста в Web IDE, переработали статистику вкладов в GitLab и не только.
Читайте дальше, чтобы узнать обо всех изменениях в GitLab 11.1
Вклад Jasper был и остаётся неотъемлемой частью в работе над обновлением GitLab до Rails 5 на протяжении нескольких последних месяцев.
Спасибо, Jasper, что постоянно делаешь GitLab лучше! В знак благодарности мы отправили тебе фирменные сувениры, в том числе толстовку, носки и тануки ручной работы.
Профессионалы в области безопасности сосредоточены на предотвращении угроз, которые могут навредить приложению. Даже после того, как код смержен в стабильную ветку или уже выпущен, этим людям необходимо отслеживать и решать проблемы, которые могут повлиять на безопасность.
Чтобы облегчить им жизнь, мы добавили в GitLab 11.1 панель управления безопасностью, которая сообщает текущий статус безопасности основной ветки в каждом проекте. Это позволяет команде безопасности легко определить, что что-то пошло не так, и понять, нужно ли что-то предпринять. Панель можно найти в меню Project. Панель интерактивная, её можно использовать для отбрасывания ложноположительных ошибок или создания решений для существующих уязвимых мест.
Документация по Панели управления безопасностью
Поскольку команды постоянно создают большие объемы кода, поиск по нему — задача не из лёгких. В этом случае критически важно наличие инструмента для управления кодом и, в частности, поиска по нему.
В этом релизе представлены новые расширенные параметры синтаксиса, которые позволяют искать по коду с использованием трёх фильтров. Теперь можно искать по имени файла (filename), пути к нему (path) и даже по расширению (** file extension**) — и результат поиска будет более точным. Эти фильтры доступны как в веб-интерфейсе, так и в API.
Для плана Core эти фильтры доступны на уровне проекта.
Для Starter и выше: если вы используете Elasticsearch, фильтры доступны также на уровне групп и на глобальном уровне.
Во всех планах подписки на GitLab.com фильтры работают только на уровне проекта, так как там ещё нет Elasticsearch. Однако, мы работаем над внедрением Elasticsearch в GitLab.com.
Документация по расширенному синтаксису поиска
Отчёты безопасности в мерж-реквестах очень полезны для обнаружения новых проблем в новом коде, даже если код еще не попал в ветку master
. Но поскольку уязвимости могут появляться до создания мерж-реквеста, иногда разработчикам нужно знать статус безопасности для конкретной ветки в конкретный момент времени.
В GitLab 11.1 набор отчётов безопасности, отображаемых в виде конвейера, дополнен динамическим тестированием безопасности приложения (Dynamic Application Security Testing, DAST) и сканированием контейнера. Достаточно посмотреть вкладку Reports
, чтобы получить всю информацию о безопасности и принять соответствующие меры.
Документация по отчетам безопасности
Статическое тестирование безопасности приложений (Static Application Security Testing, SAST) позволяет обнаружить уязвимости в коде, как только изменения попали в репозиторий. Эта информация доступна в мерж-реквесте, что позволяет исправить найденные уязвимости. Теперь они не уйдут в продакшен, так как ‘сдвиг влево’ достигается автоматически.
В GitLab 11.1 мы добавили язык Node.js в список поддерживаемых языков SAST. Теперь не нужно менять настройки в ваших проектах на Node.js, новый язык определяется автоматически и тестируется работой sast
.
В GitLab, мерж-реквесты в целом и виджет мерж-реквеста а частности — мощная фича, которая отображает большое количество полезной информации и функций. Мы постоянно оцениваем дизайн и хотим быть уверены, что информация полезна, и её легко воспринимать.
В этом релизе мы доработали дизайн информационной секции и секции конвейера. Мы отделили их от остального контента в виджете для более легкого восприятия.
Документация по мерж-реквестам
Переключение между группами должно быть простой задачей, не прерывающей ваш рабочий процесс. Чтобы сделать этот шаг проще, мы добавили выпадающее меню для групп в верхнюю панель навигации для быстрого доступа. Это избавит вас от необходимости переключаться во время работы на другой экран, чтобы найти группу, название которой тяжело запомнить. Как и в меню Projects, в Groups будут отображаться часто посещаемые группы.
Когда вы работаете над мерж-реквестом или проводите его ревью, удобно вернуться к его описанию, чтобы узнать, с какой целью и в каком контексте были сделаны изменения.
Начиная с этого релиза, вместо переключения вкладок вы можете просто открыть описание мерж-реквеста рядом с кодом прямо в Web IDE.
Мы изменили дизайн страницы с аналитикой вклада в разработку ради повышения читаемости и единообразия в пользовательском интерфейсе. Мы сосредоточились на том, чтобы эта страница могла вместить большое количество разработчиков для лучшего понимания, как участники вносят свой вклад.
Документация по аналитике вклада в разработку
В этой версии мы перерисовали список майлстоунов, включая страницы со списками проектов, групп и досок, ради единообразия в интерфейсе.
Это первый шаг в упрощении дизайна. Мы делаем его более красивым и удобным, что в конечном счёте позволит командам лучше управлять их майлстоунами.
Команды, которые используют Jira вместе с GitLab, получают возможности интеграции с панелью «Разработка» (Development) в Jira. Это позволяет пользователям Jira просматривать мерж-реквесты, ветки и коммиты из GitLab в правой панели разработки в задаче Jira. В частности, вы настраиваете интеграцию, указывая серверу Jira на группу верхнего уровня в GitLab; теперь для этого сервера будут видимы все проекты группы.
С этим релизом мы расширяем зону видимости таким образом, что все проекты в этой группе верхнего уровня, так же как и вложенные подгруппы, будут видны серверу Jira. Это расширяет возможности интеграции, позволяя более гибко структурировать ваши проекты в иерархии со стороны GitLab, не меняя управления задачами со стороны Jira.
Документация по интеграции Jira Development panel с GitLab
GitLab Flavored Markdown (GFM) позволяет пользователям легко и быстро форматировать и стилизовать текст в GitLab, в том числе в задачах, мерж-реквестах, эпиках, комментариях и в других местах. До сих пор, GitLab для GFM использовал Redcarpet, более старую реализацию Markdown. Это приводило к ряду проблем.
С этого релиза в новых файлах GFM отрисовывается при помощи современного CommonMark; а созданные ранее Markdown-файлы остаются на Redcarpet. Более детально это описано в документации по Markdown.
Помимо решения большей части упомянутых проблем, у CommonMark выше производительность. Кроме того, GitHub тоже использует CommonMark; таким образом, пользователи GitHub, перешедшие на GitLab, теперь будут использовать тот же Markdown. В будущем, когда Markdown-файлы репозиториев будут отрисованы в CommonMark, импорт проектов из GitHub в GitLab обработает файлы с Markdown точно так же.
Спасибо blackst0ne за эту фичу!
Документация по GitLab Flavored Markdown
Теперь вы можете быстро сделать задачу конфиденциальной прямо из поля комментирования; это позволит вам написать комментарий и перевести задачу в конфиденциальные, не отвлекаясь от клавиатуры.
Спасибо Jan Beckmann за его вклад!
Документация по быстрым действиям
В этом релизе мы улучшили автодополнение в эпиках. В частности, когда вы описываете или комментируете эпик, вы можете ввести знак &
, и GitLab автоматически выполнит поиск по эпикам в этой группе, а знак ~
будет вызывать поиск по меткам, так же как это уже работает в задачах (#
) и мерж-реквестах (!
).
С 2016 года, когда GitLab решил перейти на Vue.js, мы использовали его не только для создания новых фич, но и для рефакторинга существующих, чтобы улучшить интерфейс и повысить производительность.
В этом релизе мы переписали интерфейс комментариев к мерж-реквестам. Это даёт нам больший контроль над производительностью — мы будем ей заниматься в нескольких ближайших релизах. А также это поможет проще и эффективнее создавать новые фичи с использованием Vue.js. К примеру, мы уже работаем над пакетным комментированием (batch commenting).
Взгляните на текущую работу с этим интерфейсом — помимо того, что мы уже добавили в этот релиз.
Документация по мерж-реквестам
Ранее, в GitLab 10.2, мы выпустили настраиваемые доски задач, которые позволяют командам сохранить конфигурацию для доски задач. Теперь эта возможность доступна через GitLab API.
Это позволяет командам создавать свои рабочие процессы, в том числе и автоматические. К примеру, если вы хотите для каждой итерации использовать одну и ту же доску задач, теперь вы можете менять майлстоун конфигурации через API и автоматизировать это внешним скриптом между итерациями.
Документация по API для настройки досок задач
В этом релизе мы добавили заблокированное состояние (locked state) для мерж-реквестов в GitLab API – ранее оно было внутренним состоянием, недоступным через API. Мерж-реквест находится в этом заблокированном состоянии, пока исходная ветка сливается с целевой.
Открывая доступ к этому состоянию через API, мы даём возможность внешним системам надёжно обращаться ко всем мерж-реквестам, даже к тем, которые находятся в этом промежуточном заблокированном состоянии (transient locked state).
Документация по API мерж-реквестов
В настройках проекта владельцы могут перенести существующий проект в другое пространство имён (другому пользователю или группе). Это позволяет гибко организовывать проекты внутри личных и групповых пространств имён.
В этом релизе мы добавляем доступ к этим настройкам через наше API проектов, позволяя вам переместить сразу несколько репозиториев за один шаг.
Спасибо Aram Visser за эту фичу!
Документация по переносу проектов
Мы в GitLab полагаем, что каждый может внести свой вклад в разработку. Существенный шаг к этой цели — сделать создание нового проекта на GitLab как можно более простым и интуитивно понятным.
В релизе 11.1 мы вводим новую настройку, позволяющую инициализировать репозиторий за счёт добавления файла README при создании нового проекта. Если эта возможность включена, репозиторий проекта инициализируется с дефолтной веткой master
, которую сразу можно клонировать. Создаваемый файл README содержит имя и описание проекта.
Документация по созданию проектов
Пользуясь GitLab, кто угодно должен иметь возможность вносить свой вклад и пушить в проекты без необходимости изучать дополнительные сложные вещи. Ориентируясь на этот идеал, мы обнаружили, что настройка ключей SSH, основное условие для начала работы, остаётся слишком сложной.
В этом релизе мы улучшаем пользовательский опыт конфигурации ключей SSH (пункт настройки «SSH Keys») и соответствующую документацию.
Документация по ключам SSH в GitLab
В этом релизе мы упростили коммиты в Web IDE, добавив предзаполнение описания коммита и возможность одним кликом добавить коммит (Stage & Commit). Теперь при редактировании ветки, недоступной для записи (например, ветки master
), Web IDE по умолчанию предложит создать новую ветку и осмысленно предзаполнит её имя, так что вы всегда сможете создать коммит в один клик.
Раньше описание коммита не предзаполнялось, а кнопка создания коммита в таких случаях была заблокированной. Это замедляло внесение изменений и оставляло пользователя в недоумении: «Почему я не могу создать коммит?».
GitLab силён своим сообществом — и ничто не вдохновляет нас больше, чем появление новых людей, участвующих в разработке!
В этом релизе мы облегчили пользователям GitLab Core и GitLab.com поиск страницы «Внести вклад в GitLab»: мы добавили удобную ссылку, доступную прямо в меню профиля пользователя.
Подробности в нашем руководстве по внесению вклада в GitLab
Во многих случаях провайдеры SAML уже поддерживают или даже требуют двухфакторную аутентификацию для обеспечения уровня безопасности.
Начиная с GitLab 11.1 можно отключать двухфакторную аутентификацию на стороне GitLab и проводить её на стороне провайдера SAML, чтобы соблюсти его требования. Для этого мы добавили новый параметр в конфигурацию SAML.
Спасибо Roger Rüttimann за эту фичу!
Документация по SAML OmniAuth Provider
Наше файловое API позволяет производить операции CRUD (create, read, update и delete) над файлами, хранящимися в вашем проекте GitLab .
С GitLab 11.1 мы добавляем в файловое API поддержку HTTP-метода HEAD
, который позволяет читать метаданные файла. Этот запрос можно использовать, например, для проверки размера файла, чтобы принять решение о его загрузке.
Спасибо Ahmet Demir за эту фичу!
Документация по файловому API репозитория
Мы улучшили дизайн страницы Kubernetes, чтобы минимизировать отображение нерелевантной информации при добавлении кластера. С этой целью теперь мы используем отдельные вкладки для каждой опции.
Это первый шаг в серии изменений дизайна добавления кластера и управления кластерами, направленных на то, чтобы сделать его проще и понятнее.
Мы стараемся упростить управление кластерами и добавление новых. Редизайн страницы — первый шаг на этом пути
Документация по кластерам Kubernetes
После добавления меню Metrics
в Operations
стало легче и быстрее просматривать метрики производительности вашего приложения. Клик на Metrics сразу открывает панель производительности вашего окружения production
, если оно у вас есть, а также предоставляет выпадающий список для переключения на другие окружения.
В предыдущих релизах пользователю приходилось находить нужное окружение в меню Environments и нажимать кнопку Monitoring. Для переключения на другое окружение требовалось пройти весь этот процесс снова. Теперь же метрики вашего продакшена находятся всего в одном клике.
Документация по мониторингу приложений
Ещё в релизе 10.8 мы начали информировать пользователей о сторонних предложениях, которые они бы могли счесть ценными для развития своих проектов.
Бывают случаи, где эти предложения не имеют смысла, — или вы просто не хотите, чтобы они отображались в приложении. В GitLab 11.1 вы можете управлять показом сторонних предложений в области администрирования.
Документация по сторонним предложениям
GitLab можно использовать как провайдера идентификации OpenID Connect (OIDC) для внешних сервисов. Этот слой основывается на OAuth 2.0.
В предыдущий версии мы хранили подзапрос OIDC на основе хэшированной версии ID пользователя GitLab. Это могло привести к потенциально нестабильному API, так как способ хэширования может измениться в будущем. Теперь, следуя спецификации OIDC, мы храним ID пользователя прямо в подзапросе (sub
). Для обеспечения возможности миграции предыдущее значение всё ещё доступно в запросе sub_legacy
.
Документация по OpenID Connect
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 11.0 released with Auto DevOps and License Management.
Над переводом с английского работали @rishavant, @cattidourden, @ainoneko и @nick_volynkin.