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

В блоге Heroku недавно была опубликована статья о том, что сервер непрерывной интеграции GitLab CI (встроенный в сам GitLab) превзошел своего конкурента Travis CI по популярности в вопросах на Stack Overflow. Google Trends показывает аналогичный результат в популярности поисковых запросов. И наконец, во всём мире в качестве self-hosted сервиса для работы с git в двух из трех случаев используется GitLab. Спасибо вам всем за поддержку!

(MVP) этого месяца — Максим Рыдкин

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

Service Desk (EEP)

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

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

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

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

Совет: когда вы реализуете запрошенную пользователем фичу или почините баг, напишите об этом в еще одном комментарии.

Больше о Service Desk можно узнать в документации.

Канареечное развертывание (EEP)

Компания, которая внедряет непрерывную доставку continuous delivery, должна выбрать определенную стратегию развертывания. Одна из наиболее популярных стратегий — канареечные развертывания. Их смысл в том, что новая версия сначала разворачивается на небольшой части вашей инфраструктуры. Причём тут канарейки? Когда-то канареек брали в угольные шахты, чтобы определять уровень метана: когда он повышается, канарейка умирает. Аналогично, если новая версия приложения странно себя ведет, то это затронет лишь небольшую долю пользователей, и вы сможете легко исправить или откатить изменения.

В GitLab 9.1 стратегия канареечных развертываний в Kubernetes доступна сразу «из коробки». Проекты, использующие Auto Deploy, могут переключиться на обновлённый шаблон Auto Deploy, в котором эта фича уже реализована.

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

По мере выполнения конвейера, Deploy Boards явным образом отметит части инфраструктуры, использованные для канареечного развертывания.

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

Burndown Charts (EE)

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

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

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

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

Защита тегов (CE, EE)

В некоторых моделях работы с git права на создание и обновление тегов (меток) должны быть не у всех. В GitLab 9.1 появилась возможность защищать теги, чтобы ограничить возможность их создания или изменения.

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

Вся информация о защите тегов есть в документации.

Недавние поисковые запросы (CE, EE)

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

За дополнительной информацией о том, как работает история поиска, обращайтесь к документации.

Обсуждения в мерж-реквестах и задачах (CE, EE)

В GitLab вы можете начать обсуждение, комментируя строку кода в diff-e мерж-реквеста. Обсуждение является «разрешимым»: когда оно приходит к некоторому результату, его можно отметить, как решенное, подобно небольшой задаче. Начиная с версии 9.1 обсуждения не обязательно привязывать к строке кода — вы можете начинать их непосредственно в основном потоке комментариев.

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

В данном релизе мы также применили этот принцип к комментариям в задачах.

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

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

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

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

Решаемые обсуждения в мерж-реквестах

Обсуждения в задачах

Разрешение мерж-реквестов при создании новой задачи (CE, EE)

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

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

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

Интеграция с Microsoft Teams (CE, EE)

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

Первым шагом в интеграции с Microsoft Teams стала возможность добавления оповещений о событиях GitLab в комнату Microsoft Teams используя Office 365 Connectors.

Это значит, что теперь вы можете получать оповещения в Teams при пуше в репозиторий, создании или обновлении задач или мерж-реквестов. Также вы можете передавать Teams результаты выполнения конвейеров непрерывной интеграции (CI pipelines).

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

Больше информации об интеграции с Microsoft Teams в нашей документации.

Упрощение работы с шаблонами файлов (CE, EE)

В GitLab уже давно можно создавать шаблоны файлов. Например, для настройки непрерывной интеграции можно использовать шаблон файла .gitlab-ci.yml. В GitLab 9.1 пользоваться шаблонами стало еще проще.

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

Автоматическое обновление названий задач (CE, EE)

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

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

Улучшения мониторинга приложений (CE, EE)

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

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

Упрощение настроек утверждения мерж-реквестов (EE)

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

Больше информации об утверждении мерж-реквестов в нашей документации.

Улучшения аварийного восстановления (альфа-версия) (EEP)

В GitLab 9.1 входят улучшения функциональности аварийного восстановления, альфа-версию которой мы выпустили с GitLab 9.0.

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

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

Больше информации об альфа-версии аварийного восстановления в нашей документации.

Добавление мини-схем конвейеров во вкладку просмотра коммитов (CE, EE)

Теперь мини-схемы конвейеров отображаются в окне системной информации вкладки просмотра коммитов. Ранее они были доступны только при просмотре мерж-реквестов.

Больше информации о конвейерах в нашей документации.

Оповещения об успешном выполнении конвейера отключены по умолчанию (CE, EE)

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

Больше информации об оповещениях о конвейерах в нашей документации.

Иконки системных заметок (CE, EE)

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

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

Статистика использования (CE, EE)

В GitLab Community Edition добавлена функциональность статистики использования, ранее доступная в GitLab Enterprise Edition начиная с версии 8.10.

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

Больше информации о сборе статистики в нашей документации.

Фокус-режим для досок задач (EE)

Доски задач (Issue Boards) — отличный инструмент планирования и управления задачами, которыми занимаются команды разработчиков. С его помощью можно отслеживать перемещение задач между различными стадиями разработки.

В данном релизе для досок задач введен фокус-режим (focus mode), скрывающий интерфейс навигации.

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

Больше информации о досках задач в нашей документации.

Проекты с множественными образами Docker (CE, EE)

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

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

Например, теперь поддерживается хранение одновременно registry.example.com/group/project/core:latest и registry.example.com/group/project/dependencies:latest.

Спасибо André Guedes за его фантастический вклад!

Узнайте больше о реестре контейнеров в нашей документации.

Автоотмена лишних конвейеров (CE, EE)

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

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

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

Если вы хотите добавить эту функциональность, включите ее в настройках проекта CI/CD Pipelines. В последующих релизах автоотмена будет включена автоматически.

Подробности об автоматической отмене лишних конвейеров можно прочитать в нашей документации.

Триггеры конвейеров по расписанию (CE, EE)

С выходом GitLab 9.1 мы добавили альфа-поддержку планирования конвейера для его периодического запуска. Ежедневный конвейер, например, можно запускать для проверки внешних зависимостей или для ночного тестирования. Чтобы настроить плановый конвейер, добавьте триггер конвейера (Pipeline Trigger), отредактируйте его и включите триггер расписания (Schedule trigger). Используйте формат cron, чтобы установить расписание.

Читайте о триггерах конвейеров по расписанию в нашей документации.

Улучшили поддержку для заданий с большими логами (CE, EE)

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

Поскольку ошибки в задании с continuous integration (CI), постоянно возникают ближе к его концу, часто не нужно посылать и отображать лог целиком. Это особенно важно для больших проектов вроде Android, где один лишь лог задания может занимать 60 Мбайт. Если потребуется дальнейший анализ, вы всегда можете скачать лог целиком, нажав на кнопку Download.

Усовершенствованное автоматическое развертывание (CE, EE)

Вместе с поддержкой канареечного развертывания (canary deployments) мы внесли два других важных изменения в автоматическое развертывание (Auto Deploy). Во-первых, мы добавили альфа-поддержку для приложений, требующих использование базы данных, за счет автоматического обеспечения PostgreSQL по умолчанию. Для настройки полномочий и изменения названия базы данных можно использовать переменные, или вы можете отключить Postgres, отметив yes в переменной DISABLE_POSTGRES. Также мы в качестве эксперимента добавили поддержку приватных проектов, что позволит Kubernetes аутентифицироваться и скачивать контейнер приложения из GitLab Container Registry.

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

Список конвейеров теперь обновляется автоматически (CE, EE)

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

Узнайте больше о конвейерах в нашей документации.

Улучшения Elasticsearch (EE)

GitLab 9.1 EE представляет экспериментальный индексатор репозитория. Он полностью переписан, поэтому стал в 4 раза быстрее. Чтобы включить его, просто поставьте галочку в панели администратора:

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

Больше информации об Elasticsearch в нашей документации.

Изменения GitLab Runner 9.1 (CE, EE)

Также вместе с последней версией GitLab мы выпустили GitLab Runner 9.1.

Самые интересные изменения

• Расширили команду verify переключателем runner (мерж-реквест)
• Добавили в config.toml опцию log_level (мерж-реквест)
• Исправили регрессию обнаружения контейнеров кэша (мерж-реквест)
• Добавили очистку и переименование провайдера метрик докера (мерж-реквест)
• Добавили метрики гистограмм для времени создания докера (мерж-реквест)

Список всех изменений вы можете найти в CHANGELOG GitLab Runner.

Узнайте больше о GitLab Runners в нашей документации.

Улучшения производительности (CE, EE)

Для нас главным приоритетом всегда стоит ускорение GitLab. Каждый месяц мы улучшаем производительность, чтобы сделать GitLab быстрее и надежнее. Это касается не только GitLab CE и EE — повышается скорость и надежность работы GitLab.com для всех пользователей.

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

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

Узнайте больше о мониторинге производительности GitLab в нашей документации.

Улучшения пакета Omnibus (CE, EE)

SUSE Linux Enterprise Server 12.

GitLab теперь доступен на SUSE Linux Enterprise Server 12.2. Читайте инструкции для установки.

GitLab Mattermost 3.7.3

GitLab 9.1 включает Mattermost 3.7.3, альтернативу Slack с открытым исходным кодом, предоставляющую обмен сообщениями в вебе, ПК и мобильном телефоне с возможностью архивации и поиска сообщений. Улучшения этого месяца учитывают следующее поколение бета-версий приложений под iOS и Android, интеграцию в новый интерфейс командной строки и многое другое. В этой версии присутствуют обновления безопасности, поэтому рекомендуем обновиться.

Mattermost 3.7.3 появился уже в версии GitLab 9.0.4. Все, кто использует GitLab 9.0.4 или более поздние версии, должны были получить патч.

Другие улучшения

• GitLab теперь поставляется с Git 2.11 (тикет).
• Теперь вы можете использовать настройку Terraform, чтобы запустить инстанс GitLab на GoogleCompute Engine (GCE) (тикет). Разработка поддержки запуска gitlab-runner ведется в (тикете).
• Облачное хранилище Google (Google Cloud Storage) теперь можно использовать в качестве бэкэнда для Container Registry (тикет).

Узнайте больше об Omnibus GitLab в нашей документации.

Прекращение поддержки

Пакет Ubuntu 12.04

GitLab 9.1 — это последний релиз, поддерживающий пакеты Ubuntu 12.04, так как 28 апреля Ubuntu 12.04 прекратила существование. GitLab 9.2 будет по-прежнему доступен на версиях Ubuntu 14.04 и 16.04.

До 22 мая 2017.

OpenSUSE 13.2

GitLab 9.1 также будет последним релизом, поддерживающим пакеты OpenSUSE 13.2, поскольку они достигли конца своей жизни (EoL) ранее в этом году. GitLab 9.2 будет доступен для OpenSUSE 42.1.

Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: https://about.gitlab.com/2017/04/22/gitlab-9-1-released/

Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru. Над переводом работали @nick_volynkin, @rishavant и @sgnl_05 .