В данном релизе мы добавили новые новые способы убедиться, что вносимые в код изменения будут безопасны и не приведут к падению производительности, улучшили процессы планирования и совместной работы, сборки и релиза.
Не так давно мы анонсировали амбициозный проект Complete DevOps, и в данном релизе мы добавили несколько возможностей, которые способствуют его реализации. Статическое тестирование безопасности приложений и Тестирование производительности в браузере добавляют в конвейеры CI/CD соответственно проверки безопасности и производительности. Тестирование безопасности уже добавлено в Auto DevOps, тестирование производительности будет добавлено в скором времени.
Версия 10.3 включает обсуждение коммитов в мерж-реквестах, благодаря чему появилась возможность создавать обсуждения отдельных коммитов прямо в мерж-реквесте.
Благодаря нашему MVP, также стало возможным редактирование имени ветки при создании мерж-реквеста из задачи. Теперь вы сможете быстро создавать мерж-реквесты прямо из задач, не нарушая алгоритм создания веток.
Иногда картинка может сказать больше, чем тысячи слов. В версии 10.3 мы добавили в GitLab Flavored Markdown (GFM) с Mermaid поддержку блок-схем, диаграмм последовательностей, а также диаграмм Гантта.
В GitLab 10.3 добавлена поддержка нескольких кластеров Kubernetes в проекте, что позволяет изолировать итоговый (production) кластер от кластеров разработки и тестирования.
Также в версию 10.3 добавлены улучшения Auto DevOps. Теперь, при подключении Auto DevOps к проекту первый конвейер будет запускаться автоматически.
Артефакты могут быть удалены как вручную, так и автоматически по истечению определенного срока. Мы добавили строгие проверки зависимостей артефактов для того, чтобы работы CI/CD не выполнялись, если необходимые артефакты не были найдены.
В GitLab 10.3 также добавлены улучшения мерж-реквестов, эпиков, майлстоунов, зеркалирования репозиториев, интерфейса, Geo, Runner, защищенных веток, быстрых действий и досок задач.
Далее в статье мы подробнее остановимся на этих и других нововведениях GitLab 10.3.
Большое вам спасибо за то, что помогали нам создавать отличный софт с GitLab в ушедшем году! Мы желаем вам счастливого нового года, полного приятных сюрпризов! С праздником!
Виталию не привыкать к таким почестям — он уже становился MVP релиза 10.1. Для релиза 10.3 он добавил восемь мерж-реквестов, в том числе возможность редактирования имени ветки при ее создании из задачи в веб-интерфейсе и поддержку Mermaid для редактора Markdown.
Спасибо (еще раз), Виталий!
Сложно переоценить важность безопасности кода итогового продукта: его уязвимости могут привести к целому вороху неприятных последствий, от отказа системы до утечки личной информации пользователей. Проведение регулярных проверок безопасности позволяет избегать таких уязвимостей, даже если они влияют на библиотеки, импортированные из других проектов.
В GitLab 10.3 система статического тестирования безопасности приложений (Static Application Security Testing — SAST) проверяет ваш код (статический анализ) на наличие известных проблем безопасности, которые могут быть использованы в нехороших целях, например, непропатченные внешние зависимости или уязвимости межсайтовых скриптов. Данная система автоматически распознает самые распространенные языки (на данный момент поддерживаются Ruby, JavaScript и Python). Результаты ее работы отображаются прямо на странице мерж-реквеста, так что ваша команда всегда будет в курсе потенциальных проблем безопасности перед мержем кода в master и последующим развертыванием. SAST является частью Auto DevOps, благодаря чему данная функциональность работает автоматически.
Документация по статическому тестированию безопасности приложений (SAST).
В GitLab уже существует возможность отслеживания производительности итогового приложения, но, помимо этого, очень важно быть уверенным в том, что введение нового кода не приведет к ухудшению производительности. Примером таких ситуаций может быть добавление несжатого образа или добавление новой библиотеки JavaScript прямо в <head>
, что замедлит загрузку страницы. Поиск таких погрешностей вручную может оказаться трудоемким и неблагодарным процессом.
Для того, чтобы избежать таких проблем, мы добавили простой способ анализа влияния мерж-реквеста на производительность веб-приложений. Система тестирования производительности в браузере функционирует в тестовом окне браузера без заголовка и симулирует загрузку одной или нескольких страниц вашего приложения с последующим анализом. Результаты этого анализа отображаются на странице мерж-реквеста, что предоставляет наглядную иллюстрацию его влияния на производительность до того, как будет проведен мерж в master.
Документация по тестированию производительности в браузере.
GitLab отлично подходит для рабочих процессов, в которых команды комментируют и обсуждают каждую новую версию мерж-реквестов.
Однако некоторые команды взаимодействуют на уровне отдельных коммитов, даже если в пуше их несколько. Ранее реализовать такой рабочий процесс в GitLab было невозможно.
В версии 10.3 мы добавляем такую возможность. Просто перейдите на вкладку коммитов мерж-реквеста и выберите коммит для перехода на вкладку изменений. С помощью нового интерфейса теперь можно завести обсуждение с возможностью его разрешения (resolve) для каждого коммита. Такие обсуждения также отображаются в стандартной вкладке обсуждений, наряду с другими. Данное нововведение не влияет на ранее доступные рабочие процессы, что позволяет вам выбрать процесс, наиболее подходящий для вас.
Документация по обсуждениям коммитов мерж-реквестов.
В GitLab существует возможность создания мерж-реквеста и его ветки в один клик прямо из окна задачи. При нажатии на кнопку создания мерж-реквеста автоматически создается ветка с таким же названием, как и у задачи. Однако, в некоторых ситуациях присваивать ветке такое имя нежелательно, например, когда название задачи слишком длинное. В данном релизе мы вводим возможность редактирования имени ветки перед ее созданием. Эта возможность также существует при создании отдельной ветки без мерж-реквеста.
Спасибо blackst0ne за вклад в эту работу!
Документация по созданию мерж-реквеста из задачи.
С выходом данного релиза вы сможете создавать красивые блок-схемы, диаграммы последовательностей и диаграммы Гантта в описаниях и комментариях задач и мерж-реквестов. Для их создания используется GitLab Flavored Markdown (GFM). Для этого просто используйте несложный синтаксис Mermaid, который теперь поддерживается в GFM.
Спасибо blackst0ne за вклад в эту работу!
Документация по поддержке Mermaid в GFM.
GitLab может с легкостью проводить развертывание вашего приложения на различные среды с использованием кластера Kubernetes. Зачастую публикация Development, Staging, Production и Review Apps происходит одним и тем же способом. До сих пор все они существовали в одном кластере. Однако, вам может понадобиться разграничение данных и доступа, например, при наличии необходимости хранения данных production физически в другом месте.
С выходом GitLab 10.3 стало возможным настраивать для одного проекта по несколько кластеров Kubernetes, каждый из которых связан с определенной средой. Благодаря этому при публикации вашего приложения конвейеры CI/CD автоматически используют нужный кластер.
Документация по поддержке нескольких кластеров Kubernetes для одного проекта.
Ранее при подключении Auto DevOps вам приходилось ждать пуша первого коммита для того, чтобы конвейеры начали функционировать. Такое поведение было нелогичным и не интуитивно понятным.
С выходом GitLab 10.3 запуск конвейера вашего проекта происходит сразу же после включения Auto DevOps в настройках проекта, благодаря чему больше не нужно пушить еще один коммит для начала работы конвейера.
Документация по подключению Auto DevOps.
При работе с конвейерами CI/CD нередки ситуации, в которых артефакты создаются в одной работе, а используются в другой. При помощи ключевого слова dependencies
(зависимости) вы можете указать, какие артефакты из предыдущих этапов вам нужны. Однако, когда работы уже завершены, эти артефакты могут быть недоступны, например, у них мог закончиться срок давности, или они могли быть удалены вручную. Это может привести к ситуациям, в которых ваш код пытается обратиться к ресурсам, которые уже недоступны, что ведет к ошибкам, которые довольно непросто обнаружить и отладить.
В GitLab 10.3 мы вводим строгие проверки таких зависимостей. Теперь работы не будут выполняться, если все их зависимости не найдены. Благодаря такому подходу вы сразу узнаете, если какой-то необходимый артефакт отсутствует, и сможете принять необходимые меры, например, запустить абсолютно новый конвейер.
Документация по строгим проверкам зависимостей артефактов.
Логи выполнения работ CI/CD хранятся в GitLab и являются доступными для дальнейшего анализа пользователями, имеющими доступ к проекту. Эти логи могут быть удалены для предотвращения утечек информации или же просто для освобождения места.
Начиная с версии 10.3 удалять логи выполнения работ могут только пользователи с уровнем доступа Master, а также те, кто запустил соответствующую работу.
Документация по модели доступа CI/CD.
Ранее настройка проекта для использования уже существующего кластера Kubernetes происходила через страницу интеграции сервиса в настройках проекта. Такой подход диссонирует с подходом к поддержке кластеров, введенном в версии 10.1.
В GitLab 10.3 мы добавили возможность добавления существующих кластеров Kubernetes в проект напрямую со страницы Clusters. Как следствие, предыдущая версия страницы интеграции сервисов теперь становится устаревшей.
Документация по интеграции с кластерами.
Переименование и перемещение проектов происходит очень часто. Пользовательский веб-интерфейс GitLab всегда поддерживал перенаправление пользователей на актуальную локацию, а вот про действия Git такого сказать было нельзя.
Начиная с версии 10.3 действия Git также поддерживают автоматическое перенаправление. Благодаря этому все скрипты, автоматизации и клиенты Git будут продолжать исправно работать после переименования пользователя или группы.
Обратите внимание на то, что старый путь до репозитория будет запрещен к использованию во избежание пушей или пуллов из неверного репозитория.
Документация по перенаправлению при изменении пути до репозитория.
При работе с несколькими проектами сразу иногда непросто запомнить ваш уровень доступа для каждого из них. Это может привести к неприятным ситуациям и к непониманию, почему часть функциональности проекта для вас недоступна.
Очень удобно иметь способ быстро посмотреть, какой у вас уровень доступа для того, чтобы понимать, какие у вас ограничения и запрашивать повышенный уровень доступа при необходимости.
Теперь ваш уровень доступа отображается на панели задач проекта рядом с его названием, благодаря чему больше не нужно заходить в каждый проект и копаться в списке его пользователей.
Документация по ролям и уровням доступа пользователей GitLab.
Благодаря Markus Koller администраторы GitLab теперь смогут добавлять ваши собственные вспомогательные тексты на страницу создания нового проекта.
Это отличный способ предоставить пользователям дополнительные инструкции о том, как добавить новый проект. Поскольку эти поля поддерживают разметку Markdown, вы можете ссылаться на другие страницы или дополнительную документацию с более подробными инструкциями.
Документация по настройке страницы “New Project”.
Защищенные ветки позволяют блокировать доступ к пушу или мержу в ветки репозитория, предотвращая случайные изменения в коде или в рабочем процессе.
Одна из важнейших возможностей защищенных веток — определять пользователей или группы пользователей, у которых есть разрешение пушить или мержить изменения. Теперь это можно делать через API.
Документация по защищенным веткам.
Поскольку одна задача может принадлежать только одному эпику, полезно при взгляде на задачу понимать, принадлежит она уже какому-то эпику или нет. Теперь к эпику задачи можно легко перейти из бокового меню задачи.
Теперь вы можете прикреплять изображения (или любые другие файлы) к эпику через его описание. Работает по аналогии с описанием задачи (и любых других полей в GitLab в разметке Markdown). Это дает больше простора для описания эпиков за счет возможности добавить схему или макет.
Ссылки на эпики для полей в GitLab Flavored Markdown (GFM) теперь будут отображаться так же, как и ссылки на задачи, мерж-реквесты и другие объекты в GitLab. В начале стоит групповой путь, затем &
, и в конце идентификатор эпика. Во всплывающей подсказке отображается название эпика. Вставляете ссылку на эпик в текстовое поле, и GitLab отображает ее компактно и легко для чтения. Также вы можете ввести короткий путь до эпика прямо в поле GFM (например, gitlab-org&23
), и GitLab переведет его в ссылку.
Документация по отображению ссылок на эпики в GFM.
Теперь вы можете обновлять вес задачи прямо из бокового меню доски задач — так же, как и на странице самой задачи. Это позволит быстрее и проще управлять задачами при планировании и отслеживании их выполнения с помощью доски.
Появилась возможность сортировать майлстоуны на странице списка групповых майлстоунов — так же, как на странице списка проектных майлстоунов. В одной из прошлых версий мы представили групповые майлстоуны и теперь работаем над тем, чтобы добавить групповым майлстоунам все полезные функции проектных майлстоунов.
Документация по групповым майлстоунам.
Навигация по diff-файлу мерж-реквеста стала проще. Теперь имя файла отображается на отдельной строке. А если путь к файлу слишком длинный, отображается только его конец.
Подробнее о навигации по diff-файлу изменений мерж-реквеста.
При использовании быстрых действий, чтобы добавлять или удалять метки в задачу или мерж-реквест, выпадающий список подсказок сильно помогает быстрее найти то, что нужно. В последней версии автокомплит стал еще умнее: теперь при добавлении метки выпадающий список не показывает уже добавленные. А при удалении среди подсказок отображаются только те метки, которые уже добавлены.
Спасибо blackst0ne за эту возможность!
Документация по быстрым действиям с метками.
Некоторые люди предпочитают делать максимум работы на инструментах ПК, используя веб-интерфейс GitLab для задач, которые без него не сделать.
С этим релизом вы сможете создавать мерж-реквесты по email, расширяя количество разработческих задач, которые вы сможете выполнить с помощью имеющихся инструментов. Отправьте письмо GitLab, указав в теме название ветки исходника — и GitLab автоматически создаст мерж-реквест. Специальный (и уникальный для вас) email определенного проекта вы найдете, перейдя по ссылке внизу страницы мерж-реквестов проекта. Он не меняется, пока вы вручную его не обновите. Поэтому вы смело можете сохранить его в вашем почтовом клиенте.
Для разработчиков, которые разрабатывают в терминале, работают в нем с Git и посылают письма из него же: вы теперь можете делать все вплоть до создания мерж-реквеста, не покидая терминала.
Документация по созданию мерж-реквестов по email.
Многие команды замеряют время, затраченное на работу над конкретной задачей. Теперь стало возможным посмотреть сколько суммарно времени шла работа над всеми задачами в майлстоуне. Загляните в боковое меню на странице майлстоуна.
Документация по боковому меню майлстоуна.
При включенном зеркалировании пушей или пуллов репозитория все изменения будут автоматически отражаться в указанный репозиторий Git или копироваться оттуда. Но если в каком-то из пушей была измененная история Git (например, после перебазировки), зеркалирование не выполнится. Обычно никто не перебазирует ключевые ветки — например, master
— но это может произойти для ветки с отдельной функциональностью.
Чтобы предотвратить такие ситуации, зеркалировать теперь можно только защищенные ветки.
Документация по зеркалированию репозиториев.
Когда для репозитория включено зеркалирование пуллов, изменения из исходного настроенного репозитория Git в ваш репозиторий отражаются автоматически. Изменения отражаются регулярно — как только будут обнаружены путем опроса.
Мы добавили новый API для немедленного пулла изменений. Зеркалирование пулла произойдет в считанные секунды после того, как сработает вебхук события пуша в исходном репозитории.
Документация по запуску зеркалирования пуллов через API.
При включенном зеркалировании пушей все изменения репозитория пушатся в другой указанный репозиторий.
Мы изменили ограничение на зеркалирование: изменения теперь пушатся мгновенно, но не чаще, чем один раз в пять минут. Если зеркалирование разрешено только для защищенных веток, ограничение спадает до одного пуша в минуту.
Документация по зеркалированию пушей.
При включенном зеркалировании пушей или пуллов репозитория все изменения будут автоматически отражаться в указанный репозиторий Git или копироваться оттуда.
В GitLab 10.3 администраторы могут разрешить доступ к зеркалированию пушей и пуллов только для администраторов, чтобы репозитории в инстанс или из инстанса GitLab не копировались лишний раз.
Документация по ограничению зеркалирования репозиториев.
Управление нодами Geo и их отслеживание значительно упростились за счет разделения интерфейса на отдельные части: для отслеживания и для добавления и редактирования нода Geo.
Документация по улучшенному отображению нодов Geo.
В GitLab 10.2 Postgres HA стала полностью доступна, что упростило настройку кластера базы данных Postgres на продакшене с использованием пакета Omnibus.
Теперь мы сделали ее еще проще. Представляем вам новые роли Postgres. Эти роли значительно уменьшают количество действий, необходимых для настройки отдельных нодов базы данных, автоматически выключая все остальные функциональности и компоненты.
Документация по упрощенной настройке PostgreSQL HA.
GitLab 10.3 включает Mattermost 4.4.5, альтернативу Slack с открытым исходным кодом. Новая версия включает бета-релиз поддержки плагинов и многое другое.
Документация по GitLab Mattermost 4.4.5.
Также с этим релизом выходит GitLab Runner 10.3. GitLab Runner — проект с открытым исходным кодом, используемый для запуска работ CI/CD и пересылки результатов обратно в GitLab.
Самые важные изменения:
--checkout --force
в git submodule update --init
<nil>
в конец логов syslogПолный список изменений в CHANGELOG GitLab Runner.
Документация по GitLab Runner 10.3.
Документация по улучшениям Omnibus.
Мы улучшили балансировщик нагрузки баз данных, входящий в GitLab Enterprise Edition. Теперь он может обрабатывать слишком медленные копии. Вместе с регулировкой проверок статусов копий это помогает уменьшить число запросов, необходимых для проверки доступности копии.
Эти изменения позволяют балансировщику нагрузки баз данных не посылать доступные только для чтения запросы копиям в случаях, когда они слишком медленно копируют первичную базу данных.
Подробнее вы можете прочитать в мерж-реквесте о том, как мы обрабатывали устаревшие копии в балансировщике нагрузки базы данных.
Документация по балансировщику базы данных.
С каждым релизом мы делаем огромное количество вещей, направленных на улучшение производительности. Мы считаем, что нужно ускорять не только отдельные инстансы GitLab, но и весь GitLab.com, которым пользуется больше миллиона человек.
В GitLab 10.3 мы выпускаем 24 улучшения производительности для мерж-реквестов, CI/CD, Prometheus, фронтэнда и многого другого. И отдельно хотим упомянуть:
Полный список улучшений производительности.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 10.3 released with Static Application Security Testing and Browser Performance Testing.