MVP (Most Valuable Person) этого месяца — Джеймс Муннелли (James Munnelly): он интегрировал Kubernetes в GitLab CI. Эта фича позволяет легко запускать CI-тесты на кластере Kubernetes. Джеймс открыл этот мерж-реквест около года назад, а затем терпеливо и настойчиво дорабатывал его по результатам ревью.

Спасибо, Джеймс!

Аналитика цикла разработки ПО (Cycle Analytics)

Первый принцип conversational development (convdev) — уменьшение времени цикла разработки ПО, то есть времени, за которое идея реализуется и выпускается на production. Чем короче время цикла, тем выше эффективность вашей команды.

В GitLab 8.12 мы реализовали Cycle Analytics — инструмент, который показывает среднее время цикла в вашей команде.

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

Страница Cycle Analytics находится во вкладке Pipelines каждого проекта.

Подробнее о Cycle Analytics

Глобальный поиск кода (EE)

Если на вашем инстансе GitLab Enterprise Edition настроен Elasticsearch, вам станет доступен поиск по коду всех проектов сразу.

Используйте поиск так же, как вы делали это раньше; только теперь GitLab покажет вам результаты из всех проектов, к которым у вас есть доступ.

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

Версии мерж-реквестов

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

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

Подробнее о версиях мерж-реквестов

Защита от публикации чувствительной информации (EE)

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

К сожалению, такое случается довольно часто.

Например, вы пишете git commit -am'хотфикс' && git push, а потом обнаруживаете, что закоммитили то, что не следовало.

В GitLab появилась новая проверка при пуше (push rule), которая блокирует коммиты с чувствительной информацией. Просто поставьте соответствующую галочку, и GitLab не позволит закоммитить небезопасные файлы, например .pem и .key.

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

Подробнее о проверках при пуше

Review Apps (экспериментальная фича)

Мы внесли несколько изменений в GitLab CI. Вместе они создают немного волшебства.

Теперь вы можете задавать имена окружений (environments) в переменных CI. Вы также можете указывать URL для конфигурации окружения в файле .gitlab-ci.yml. Вместе эти две возможности составляют основу первой итерации Review Apps.

Review apps — это автоматически создаваемые окружения, в которые развертывается код из каждой ветки. Это означает, что теперь каждому мерж-реквесту автоматически назначается работающее окружение.

Идея этой фичи была взята у Heroku Review Apps, а компания Heroku заимствовала ее у Fourchette.

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

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

В данный момент мы пишем новую статью с примерами Review Apps.

Авторизация в LFS через SSH

Если вы привыкли делать пуши через SSH, то вводить свои логин и пароль каждый раз при использовании LFS наверняка несколько расстраивало.

GitLab теперь использует ваш SSH-ключ при использовании LFS. То есть, если вы используете LFS, подключаясь через SSH, вам больше не придется вручную вводить данные для идентификации

Передача файлов LFS все еще производится через HTTP.

Включение и отключение LFS

Git LFS (Large File Storage) — это хорошо, но использование этой фичи, как подразумевается в названии, может потребовать много места на диске. Чтобы вы меньше волновались о расходовании дискового пространства, вы можете включать и выключать LFS для всего инстанса GitLab, для группы проектов или для конкретного проекта.

Ограничение размера проекта (EE)

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

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

Подробнее в документации об ограничении размера репозитория

Улучшения LDAP/Active Directory

В этом релизе добавлены некоторые усовершенствования в поддержку LDAP/Active Directory для GitLab CE и EE:

• CE/EE - Запрашивать только LDAP-атрибуты пользователя/группы, которые потребуются GitLab (CE 6187 и EE 712), уменьшая количество передаваемых данных между GitLab и сервером LDAP/Active Directory. Это также уменьшает количество занятой объектами памяти внутри GitLab .
• EE - Ускорение выборок вложенных групп и пагинрованных запросов пользователей (для больших групп) (719)
• EE - Добавлена опция ‘Sync now’ на страницу члена команды, если присутствуют групповые ссылки LDAP (704)

Восстановление токенов двухфакторной аутентификации через SSH

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

Подробнее в документации о восстановлении двухфакторной аутентификации через SSH.

Фильтр тегов по именам

Хотите быстро найти тег? Используйте для этого новый удобный фильтр в верхней части страницы:

Дополнения в API

В GitLab 8.12 мы расширили наш API:

• Появилась возможность устанавливать параметр request_access_enabled для групп и проектов
• Добавлены вызовы API notification_settings
• Добавлено API BroadcastMessage
• Теперь вы можете форкаться в конкретные пространства имен (namespaces) через API
• Возможность включать/выключать запросы на доступ для групп и проектов
• Добавлено поле web_url в тикеты, мерж-реквесты и сниппеты (функциональность реализована членами нашего сообщества)
• Возвращение sha и merge_commit_sha в API-запросе для мерж-реквестов. (функциональность реализована членами нашего сообществ)
• Распознавание пометки конфиденциальности тикета (функциональность реализована членами нашего сообществ)
• Добавлена настройка проекта only_allow_merge_if_build_succeeds. (функциональность реализована членами нашего сообществ)
• Добавлен API-вызов, чтобы проверить ваш .gitlab-ci.yml файл на синтаксическую корректность (lint) (функциональность реализована членами нашего сообществ)
• Добавлено API для отображения ручных действий в разделах «Среды развертывания» (Environments) и «Развертывания» (Deployments)

Улучшенный инструмент импорта с GitHub

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

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

Подробнее в документации об импорте репозиториев из GitHub.

Массовое управление мерж-реквестами

Теперь вы можете редактировать несколько мерж-реквестов сразу. Одновременно изменить в нескольких мерж-реквестах можно: статус, этап (milestone), ярлык (label), описание или разработчика, на которого назначен мерж-реквест.

Управление проектами с большим количеством мерж-реквестов станет намного легче!

Группировка билдов

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

Расширенная подсветка синтаксиса

С переходом на rouge 2.0.6, мы добавили подсветку синтаксиса для JSX, Prometheus, mxml, 1C (1С, Карл!), turtle/trig, vhdl, и улучшили подсветку для Swift 3.

Интеграция Sentry в Workhorse

GitLab-Workhorse теперь может отправлять ошибки приложения в Sentry.

Подробнее в документации по GitLab-Workhorse

GitLab Runner 1.6

Также мы сегодня выпускаем GitLab Runner 1.6. Ключевые моменты:

• Kubernetes executor (30 and 277), this allows Kubernetes to automatically scale the number of CI runners. All your builds will be processed immediately without having idle machines running when it’s not busy.
• Autocompletion of /ci in GitLab URL while registering the Runner (289)
• Configuration options for specifying scripts executed before clone/fetch is done and before build script is executed (106)
• Improvements in passing CA certificates to builds (299)
• Improvement in disabling recursive submodules fetching/cloning (314)
• Improve docker machine logging (234)
• Add possibility to specify a list of volumes to inherit from another container (236)
• Generate a BuildError instead of SystemError when Docker/Kubernetes image is missing (295)

Посмотреть полный список изменений можно в changelog-файле Runner.

GitLab Mattermost 3.4

GitLab 8.12 включает в себя Mattermost 3.4, альтернатива Slack с открытым исходным кодом, последний релиз которого предлагает 700 интеграций с полной поддержкой Markdown через Zapier, упрощенного бота и аутентификацию через OAuth2, а также (добавленную представителями нашего сообщества) интеграцию с Gitter, Heroku, Pivotal Tracker, Chef, Ansible и Yunohost.

Улучшения производительности

• Процессы Sidekiq теперь используют пул соединений при использовании механизма кэширования Rails: мерж-реквест
• Теперь используется гем oj для ускорения обработки JSON: мерж-реквест
• Колонка projects.last_activity_at обновляется только один раз в час, чтобы уменьшить нагрузку на базу данных: мерж-реквест
• Колонка projects.pushes_since_gc перемещена из базы данных в Redis, чтобы уменьшить нагрузку на базу данных: мерж-реквест
• Проверка защищенных веток не производится, когда имя ветки неизвестно, что уменьшает количество времени, затраченного на этот процесс: мерж-реквест
• Проверка, может ли кто-нибудь закрыть комментарий к коммиту, делается только в том случае, когда комментарии вообще можно закрывать: мерж-реквест
• Таблица ci_runners теперь обновляется реже, чтобы уменьшить нагрузку на базу данных: мерж-реквест
• Уменьшено число запросов к базе данных, используемых для вкладки “Builds” для коммитов/мерж-реквестов: мерж-реквест
• Уменьшен максимальный размер календаря действий: мерж-реквест

Изменения в правах доступа для сборок

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

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

• У нас уже есть система прав доступа для пользователей (базирующаяся на том, к какой группе или проекту принадлежит пользователь)
• Мы знаем, какой пользователь запускает билд (неважно, как именно — используя пуш в Git, через веб или через триггеры).
• Мы знаем, что позволено этому пользователю.
• Сборкам, которые были запущены пушем, мы даем те же права, что имел пользователь, сделавший пуш (согласитесь, удобно, когда ваша сборка имеет доступ ко всему, к чему есть доступ у вас)
• Мы можем создавать уникальные короткоживущие токены, предоставляющие необходимый доступ на время жизни сборки.
• Это очень хорошо соотносится с нашей философии «все должно быть интегрировано между собой)
• Такой подход позволяет делать с правами доступа много интересного: например, давать только отдельным пользователям доступ к runners, секретным переменным и средам развертывания (environments).

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

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

Подробнее о правах доступа сборок и изменениях в связи с этим смотрите нашу документацию.

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

Подмодули в CI

Подмодули (submodules) — это одна из причин, почему мы переработали права доступа для сборок. Теперь использовать подмодули в ваших CI-сборках стало гораздо проще.

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

[submodule "tools"]
    path = tools
    url = git@gitlab.com/group/tools.git

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

[submodule "tools"]
    path = tools
    url = ../../group/tools.git

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

Последний шаг — сказать GitLab CI выкачать подмодули:

before_script:
  - git submodule update --init --recursive

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

Другие изменения

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

Барометр обновлений

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

(Только для EE) реиндексация Elasticsearch

Мы изменили структуру индекса Elasticsearch для репозиториев, используя связи типа «родитель-потомок». Вам придется полностью пересобрать весь индекс ES. Также Elasticsearch 2.3.x содержит баг, который вызывает отказ всех запросов, одновременно использующих фичу “highlight” и связь «родитель-потомок», в связи с чем мы рекомендуем использовать версию 2.4 или более новую. После обновления на GitLab 8.12, вам потребуется удалить старый индекс и пересобрать новый.

Чтобы удалить старый индекс, сделайте следующий запрос к Elasticsearch:

curl -XDELETE 'http://localhost:9200/gitlab-production/'

Затем пересоберите новые индексы, как описано в документации по интеграции Elasticsearch

Обновление Ruby

В предыдущем релизном посте мы упоминали, что поддержка Ruby 2.1.x в GitLab 8.13 будет прекращена. Мы изменили свое решение и не будем прекращать поддержку Ruby 2.1.x в ближайшем будущем.

Мы по-прежнему рекомендуем вам обновиться до Ruby 2.3, если вы запускаете установку из исходников, так как это та же версия, которая поставляется вместе с Omnibus.

Расширенная отправка пользовательских данных (EE)

Чтобы дать нам больше информации о сценариях использования нашего продукта, GitLab 8.12 EE теперь отправляет на сервер дополнительные данные.

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

Подробная информация — в соответствующем мерж-реквесте

Секретный ключ GitLab-Workhorse

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

Если вы используете Omnibus, или вы устанавливали GitLab из источника с нашим официальным init.d скриптом, ваш секретный ключ сгенерируется и установится автоматически. Если вы используете свой init.d скрипт или пользуетесь пакетами, созданными не в GitLab Inc., вам понадобится установить опцию -secretPath в GitLab-Workhorse.

Еще кое-что

Мы предполагаем, что вы обновляетесь с последней версии. Если это не так, ознакомьтесь с «барометрами обновлений» промежуточных версий, которые вы пропускаете. Если вы обновляетесь с GitLab версии до 8.0 и у вас включена CI, вам следует сначала обновиться до GitLab 8.0

Пожалуйста, помните, что исходные пакеты Omnibus остановятся, запустят миграции и запустятся снова вне зависимости от того, насколько «большое» или «маленькое» получится обновление. Чтобы изменить это поведение, добавьте файл /etc/gitlab/skip-auto-migrations.

Установка

Если вы устанавливаете GitLab с «нуля», прочитайте соответствующий раздел.

Обновление

Следите за нашими обновлениями.

Enterprise Edition

GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп. Подробную информацию можно посмотреть в описании GitLab EE.

GitLab EE доступен только по подписке.

Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах.

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