GitLab спроектирован таким образом, что каждый участник проекта может вносить свой вклад, независимо от размера команды и местонахождения ее участников.
Зачастую в процессе разработки продукта несколько человек работают над одной задачей: например, разработчики фронтэнда и бэкэнда, дизайнер интерфейса, тестировщик и менеджер продукта. С выходом GitLab 9.2 все они могут быть назначены исполнителями одной задачи, что упрощает процесс совместной разработки и позволяет наглядно отображать их общую область ответственности.
Также в версии 9.2 положено начало процесса локализации GitLab: аналитика цикла разработки (Cycle Analytics) теперь доступна на испанском и немецком языках. Локализация GitLab будет продолжена в последующих релизах, чтобы каждый мог вносить свой вклад независимо от родного языка.
Кроме того, разработчики получили больше контроля над временем выполнения конвейеров CI/CD. Теперь можно составлять расписание выполнения конвейеров, что позволяет автоматизировать периодические задачи, такие как ночные сборки, профилактика или подтверждение внешних зависимостей.
Dosuken добавил дополнительные параметры поиска в интерфейс конвейеров. Это нововведение открывает множество возможностей: например, теперь можно с легкостью сформировать запрос на последний конвейер определенной ветки. Также Dosuken внес существенный вклад в прошлый релиз — он заложил основы выполнения конвейеров по расписанию. Спасибо, Dosuken!
При работе с GitLab нередко появляются задачи, которые требуют совместных усилий сразу нескольких человек. Ранее в таких ситуациях было сложно понять, на кого назначена задача; это было особенно актуально для организаций, в которых исполнители не контактируют друг с другом ежедневно. С выходом GitLab 9.2 становится возможным назначить исполнителями одной задачи столько пользователей, сколько необходимо. Все они будут обладать равным уровнем ответственности и получать те же оповещения, что и в предыдущих версиях. Все исполнители отображаются в списке задач и досках задач, каждый из них может отслеживать свою связь с задачами на своей панели управления.
Обратите внимание: в связи с этими изменениями параметр API задач assignee_id
устарел, вместо него нужно использовать assignee_ids
. Также, вместо объекта JSON assignee
нужно использовать assignees
.
Больше информации в нашей документации
Hola Mundo, Hallo Welt! Мы рады сообщить, что, начиная с данного релиза, мы приступаем к работе над локализацией GitLab. Будем рады вашей поддержке в этом начинании!
В версию 9.2 добавлены инструментарий и инфраструктура для перевода GitLab на любой язык мира. Пока что в тестовых целях мы перевели только одну страницу (Cycle Analytics) на испанский и немецкий. В следующих версиях мы будем переводить новые страницы, а также добавлять другие языки. Если вы хотите помочь нам в этом — обратитесь к инструкции.
Для смены языка GitLab нажмите на свою иконку в правом верхнем углу экрана и зайдите в настройки (Settings).
Больше информации об аналитике цикла разработки в нашей документации
В большинстве проектов конвейеры CI/CD запускаются для каждого нового коммита — таким образом, все изменения в коде проходят сборку, тестирование и развертывание. Однако, существуют ситуации, в которых требуется запуск конвейера по определенному расписанию.
С выходом GitLab 9.2 становится возможным настроить запуск конвейеров тогда, когда нужно, и так часто, как нужно. Ежедневный и еженедельный запуск конвейеров, проверка внешних зависимостей или просто профилактические запуски — теперь все это можно легко настроить.
Данная функциональность полностью заменяет альфа-версию интерфейса для триггеров конвейеров по расписанию.
Больше информации о планировании запуска конвейеров в нашей документации
Мы хотим, чтобы GitLab был как можно лучшим инструментом для нативной облачной разработки. Для этого важно, чтобы вы могли легко начать работу с Kubernetes. Поэтому мы с радостью сообщаем, что с версией 9.2 выходят официальные Helm-чарты GitLab.
Helm — это инструмент управления пакетами, который позволяет проводить развертывание, апгрейд и настройку приложений в кластерах Kubernetes. GitLab и Kubernetes прекрасно взаимодействуют друг с другом: все идеи, представленные в нашем видео Idea to Production, такие как автоматизация масштабирования CI и развертывания в ваши кластеры, легко реализуются с минимумом дополнительной настройки.
Больше информации об установке GitLab при помощи Helm-чартов в нашей документации
В большинстве случаев нелегко отследить влияние определенного мержа на производительность системы. Зачастую, за данные о производительности отвечает отдельный инструмент, к которому у команды разработчиков даже нет доступа. Мы хотим, чтобы у разработчиков была возможность получать эти данные для каждого изменения, которое они вносят. Интеграция с Prometheus является большим шагом к достижению этой цели.
Начиная с GitLab 9.2 изменения в потреблении памяти после развертывания отображаются прямо в мерж-реквесте. Теперь разработчики могут отслеживать изменения в производительности, не отвлекаясь от привычного процесса работы. В последующих релизах мы планируем добавить другие метрики производительности.
Больше информации об отслеживании воздействия мерж-реквестов на потребление памяти в нашей документации
Начиная с версии 9.0, в GitLab Geo входит альфа-версия аварийного восстановления. Мы стремимся улучшать ее с каждым новым релизом, и GitLab 9.2 не стал исключением. В новой версии мы сделали аварийное восстановление более удобным: смысл элементов управления стал более очевидным, а отчеты о процессе репликации — более подробными.
Также улучшился механизм репликации репозиториев: теперь повторная синхронизация для репозиториев, поврежденных из-за ошибок синхронизации, происходит автоматически. Кроме того, при обновлении основной базы данных происходит ее автоматическая синхронизация со вторичными базами.
Больше информации о GItLab Geo в нашей документации
Поскольку страница задачи является основным местом совместной работы, ее содержимое постоянно меняется. Начиная с версии GitLab 9.2, название и описание задач обновляются автоматически, без обновления страницы. Так что теперь для того, чтобы постоянно видеть последнюю версию задачи, достаточно просто держать ее вкладку открытой. Даже название вкладки в браузере обновляется автоматически.
Кроме того, при редактировании описания задачи добавляется системная заметка, благодаря чему можно просмотреть полную историю изменений задачи просто пролистав ее комментарии. Эти изменения затронули и комментарии — они таким же образом автоматически обновляются при их редактировании.
Больше информации по задачам в нашей документации
Теперь вы сможете одним кликом удалять фильтры в строке поиска задач и мерж-реквестов.
Также мы изменили стиль ярлыков в строке поиска: теперь они соотносятся по цвету с остальными ярлыками по всему приложению.
Подробности о поиске задач и мерж-реквестов
Мы добавляем больше возможностей расширенного поиска за счет интеграции с Elasticsearch. Если вы настроили Elasticsearch, вы можете искать точные фразы (в двойных кавычках) или неупорядоченный набор ключевых слов, по совпадению части слова или использовать другие возможности поискового синтаксиса. (Заметьте, что это относится к строке поиска в правом верхнем углу на любой странице GitLab, но не к поиску в списках задач и мерж-реквестов.)
Также благодаря Elasticsearch стал возможным глобальный поиск по всем вики в вашем инстансе.
Узнайте больше о расширенном поиске с помощью Elasticsearch
В каждой итерации GitLab мы стараемся сделать путь от идеи к производству более быстрым и легким.
Эта новая маленькая фича позволит вам создать мерж-реквест прямо со страницы задачи, а необходимую для этого ветку GitLab создаст автоматически. Это особенно полезно, когда вам нужно сделать небольшой коммит прямо из интерфейса GitLab.
О том, как создать мерж-реквест из задачи
В сниппетах (даже в личных) часто происходит совместная работа. В этом обновлении появятся треды комментариев для каждого личного сниппета — так же, как и для сниппетов проекта.
Дополнительно о сниппетах можно прочитать в нашей документации
При просмотре файлов GitLab многие файлы, например, SVG & Markdown, отображаются в отрендеренной форме. На странице просмотра файла появился удобный маленький переключатель между режимами просмотра исходного кода и отрендеренного файла.
В GitLab 9.1 мы запустили поддержку установки GitLab на GCE через Terraform компании Hashicorp. В версии 9.2 мы также добавляем возможность разворачивать GitLab Runner, дополнив этим принцип «от идеи к производству».
Репозиторий с конфигурацией Terraform для GitLab
Артефактом может быть любой файл; вы можете добраться до этого файла с помощью поиска по архиву прямо в пользовательском интерфейсе. GitLab 9.2 расширил возможности этого поиска: теперь у файлов PDF, картинок, видео и других форматов будет предпросмотр прямо в поиске артефактов заданий — их больше не нужно скачивать.
Больше информации о поиске артефактов заданий в нашей документации
В GitLab есть несколько путей до конкретных фич. После введения вложенных групп эти фичи могли стать недоступными для тех проектов или групп, названия которых конфликтуют с этими путями. Например, для проекта под названием ‘badges’ бэйджи (badges) статусов сборки или покрытия стали недоступны.
Чтобы избежать таких недоразумений, мы убрали возможность создавать проекты или группы с названиями, которые могут конфликтовать с существующими маршрутами GitLab.
Если у вас были проекты или группы с названиями одного из таких путей, они автоматически переименуются при обновлении. Проект с названием badges
будет называться badges0
.
Учтите, что настройки git remote
нужно будет обновить вручную, например, так:
git remote set-url origin git@gitlab.com:the-updated-path/the-updated-name.git
Полный список зарезервированных слов вы можете посмотреть в файле dynamic_path_validator.rb
. Список существующих проектов и групп, которых в этом релизе затронуло автоматическое переименование, можно найти в миграции, которая их переименовала.
Подробности о создании подгрупп
Начиная с GitLab 9.2 исходные ветки в мерж-реквестах по умолчанию удаляются. Если вы хотите сохранить ветку даже после мержа, вам нужно отключить опцию в виджете мерж-реквеста до его принятия.
Может так случиться, что кто-то (случайно или умышленно) использует в .gitlab-ci.yml
один и тот же путь для ключевых слов cache
(кэш) and artifacts
(артефакты), что может вызвать ситуацию, когда залежавшийся кэш может случайно перезаписать артефакты, которые используются в конвейере.
С этого релиза артефакты можно восстанавливать после кэширования — чтобы убедиться, что они сохранятся и будут доступны даже в критической ситуации.
GitLab 9.2 включает Mattermost 3.9, альтернативу Slack с открытым исходным кодом. В этом релизе мы добавили в нее новый каталог интеграций и поддержку польского языка, дополнили десктопные приложения проверкой орфографии и добавили еще много полезного.
Версия включает обновления безопасности. Рекомендуем обновиться.
Реестр контейнеров GitLab (GitLab Container Registry) обновился с версии 2.4 до версии 2.6.1.
Интерфейс мерж-реквестов позволяет выбирать отдельных ревьюеров, которые смогут принять (подтвердить) этот реквест. На выбор предлагаются только участники проекта, а также группы, к которой принадлежит проект (parent group), и группы, которым предоставлен доступ к проекту (project share). Поэтому вы сможете легко найти нужных пользователей.
Подробнее о настройке ревьюеров мерж-реквестов
В этом релизе появилась возможность ссылаться на устаревший дифф прямо из треда обсуждения мерж-реквеста. Это позволит быстро обращаться к содержимому старых коммитов в процессе разработки, совместной работы и ревью. Вы даже сможете оставлять комментарии в тех устаревших диффах.
Если производительность продукта поменялась, то первый вопрос — менялось ли рабочее окружение? GitLab 9.2 теперь быстро отвечает на этот вопрос, отображая все развертывания в окружении прямо на доске мониторинга. Это позволяет сразу видеть зависимость между изменениями в производительности и новой версией приложения (и все это не покидая GitLab).
Документация о мониторинге окружения
Для ручных действий теперь требуются те же права доступа, что и на запись в репозиторий, что позволит контролировать, кто может их совершать. Например, теперь можно оставить право на ручной запуск задачи по развертыванию кода из стабильной ветки на production только для пользователей, имеющих право на коммит в эту ветку.
Это очень важная часть в списке улучшений системы безопасности, которые мы добавляем в GitLab для защиты развертывания в ваших проектах. Подробности можно прочитать в этой задаче.
Когда вы совершаете коммит новой части кода в проект с continuous integration (CI), обычно вы ожидаете увидеть отметку, которая обозначает, что конвейер выполнен успешно, и все сработало так, как было задумано. В случае, если что-то пошло не так, нужно как можно быстрее узнать подробности. Но многочисленные переходы по каждому из этапов и заданий не очень вдохновляют, особенно если конвейер сложный.
В GitLab 9.2 на странице информации о конвейере (в разделе Pipelines выбрать конкретный конвейер) появилась вкладка Failed Jobs. На ней можно посмотреть логи всех проваленных заданий и оценить общую картину выполнения конвейера.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: https://about.gitlab.com/2017/05/22/gitlab-9-2-released/
Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru. Над переводом работали @nick_volynkin, @rishavant и @sgnl_05 .