Эта статья — перевод релизной статьи компании GitLab. Релизы выходят каждый месяц 22 числа. Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8 В новом GitLab 8.11 столько всего интересного, что мы с трудом сдерживаем себя в рамках конструктивного повествования! Итак, в новой версии появились: MVP этого месяца — Clement Ho. Спасибо ему за мерж-реквесты и отзывчивость в работе над задачами. Тикеты (issues) в GitLab — очень гибкий инструмент. Они могут содержать ссылки друг на друга, можно обозначить их приоритеты, можно отсортировать по популярности. Доска тикетов добавляет новый способ работы с ними. Теперь можно настраивать рабочие процессы (workflows) и быстро получать информацию о состоянии тикетов. Всё это доступно на простой и приятной глазу доске, похожей на те, что используются в Канбане или Скраме.  Доска создается для каждого проекта автоматически. По умолчанию все открытые тикеты формируют список-бэклог (Backlog), а все закрытые появляются в списке завершённых (Done list). Добавляя новые списки, вы создаёте новые рабочие процессы. Принадлежность тикета к списку определяется меткой. При добавлении тикета в список к ней добавляется соответствующая метка, при удалении из списка — метка удаляется. Если у вас раньше были метки вроде фронтенд, бэкенд и дизайн — самое время сделать из них списки. Тикеты появятся в них автоматически. И, конечно, тикет может принадлежать более чем одному списку. Если хотите посмотреть на эту фичу в действии, загляните на доску GitLab CE версии 8.12. Мержи в крупных и активно разрабатываемых проектах обычно вызывают много проблем. Мы хотим, чтобы у вас был встроенный инструмент для разрешения конфликтов. Поэтому теперь можно это делать прямо в интерфейсе GitLab.  Когда мерж блокируется конфликтом, можно просто нажать кнопку "Resolve these conflicts" и перейти в интерфейс разрешения. Там можно выбрать нужные строки и закоммитить полученный результат. Разумеется, так получится разрешить далеко не все конфликты. Но мы надеемся, что в большинстве случаев этот инструмент поможет вам ускорить прохождение мерж-реквестов. Теперь в Enterprise Edition можно настраивать разрешения на пуш или мерж в ветку не только для подгрупп пользователей (как developers или owners), но и для конкретных пользователей.  Новые настройки можно совмещать с другой функциональностью, в том числе с разрешениями для подгрупп. Например, можно разрешить пушить непосредственно в ветку только тимлидам Пете и Маше, но подтверждать мерж-реквесты в эту ветку — всем членам группы уровня developer и выше.  Для каждого действия (пуш и мерж) можно настроить любое количество авторизованных пользователей. В мерж-реквестах бывают длинные ветки комментариев, в которых можно запутаться. Но каждый из них важен. Мы добавили возможность отметить комментарий или целую ветку как обработанную и закрыть её.   В мерж-реквестах теперь также есть счётчик незакрытых обсуждений и удобная кнопка перехода к к следующему открытому обсуждению.  Конвейеры в GitLab могут иметь достаточно сложную структуру с множеством последовательных и параллельных сборок. Теперь можно посмотреть на схему конкретного конвейера, отображающую его строение и состояние. Такая схема наглядно показывает происходящие в нём процессы.  Просто кликните на конвейере на странице мерж-реквеста или в списке конвейеров. Вы увидите схему этого конвейера с отображением выполненных, проваленных, активных и ожидающих сборок. Возможность стандартизировать тикеты и мерж-реквесты с помощью шаблонов уже была в GitLab Enterprise Edition. Начиная с GitLab 8.11 шаблонов может быть много — например, один для ошибок, а другой для предложений. А сама возможность есть во всех версиях: GitLab.com, GitLab CE/EE. Шаблоны пишутся в разметке Markdown и лежат в вашем репозитории соответственно в папках .gitlab/issue_templates и .gitlab/merge_request_templates:  Цель этой фичи — улучшить внешний вид и полноту предложений, сообщений об ошибках и мерж-реквестов.  Теперь в GitLab есть слеш-команды (/command) — так же, как в IRC, HipChat, Mattermost или Slack. Они позволяют менять метки, назначать исполнителей, подписываться и отписываться от тикетов и делать многое другое — быстро и не отрывая рук от клавиатуры. Команды работают в описании тикета или мерж-реквеста, а также в комментариях.  Как ими пользоваться:  Можно использовать слеш-команды даже при создании нового тикета или реквеста:  Если последовательно указать несколько команд, то все они будут выполнены. Несколько идей, как можно использовать слеш-команды: Мы сами с нетерпением ждём ваших рассказов о том, какие ещё способы использования вы изобретёте. Koding позволяет запускать среду разработки в облаке, использовать единые настройки этой среды для всей команды и даже использовать локальный редактор. Благодаря этому не нужно тратить время на установку и настройку стека для каждого нового компьютера и при любом изменении. Начиная с версии 8.11 GitLab поддерживает интеграцию с Koding. Теперь одним нажатием кнопки можно выкачать проект целиком или отдельный мерж-реквест и открыть его в полноценной облачной IDE. (обратите внимание, что на GitLab.com интеграция с Koding пока не добавлена). Включите поддержку Koding в Admin > Application settings  Настройте Koding для работы с вашим проектом:   И все! Теперь вы можете быстро выкачать любой мерж-реквест, ветку и коммит проекта в полноценную IDE.  Мы подготовили небольшое видео, показывающее процесс работы связки Koding + GitLab: Для того, чтобы узнать больше о Koding в GitLab, обратитесь к нашей документации. Теперь конвейеры отображаются в мерж-реквестах:  Нажмите на конвейер, чтобы увидеть его схему и билды, относящиеся к нему. Теперь вы можете указывать URL для своих сред развертывания (environments):  Благодаря этому GitLab показывает статус развертывания для мерж-реквестов в случаях, когда развертывание происходит автоматически при мерже:  После успешного мержа GitLab покажет вам ссылку на среду развертывания, что позволяет увидеть результат мерж-реквеста в один клик. Для упрощения интеграции с конвейерами GitLab мы добавили веб-хуки для них. Они срабатывают при создании, запуске или завершении работы конвейера. Для того, чтобы добавить веб-хук, выберите Webhooks в меню Settings вашего проекта. Теперь редактор GitLab поддерживает подсветку и позволяет скрывать блоки кода.  Теперь при пуше на GitLab появляются ссылки на создание мерж-реквеста, а также на все мерж-реквесты, имеющие отношение к текущему.  Появилась возможность создавать значки, показывающие покрытие тестами вашего проекта:  Если вы не использовали отображение покрытия в GitLab, подключите его в настройках конвейеров: pipelines/settings. При выдаче доступа к проекту одиночному пользователю, либо группе, теперь можно установить определенную дату, после которой доступ к проекту будет для них закрыт. Это упрощает работу с правами доступа для временных членов команды. В GitLab 8.10 были добавлены множественные точки монтирования (mount points). В GitLab 8.11 появилась возможность перемещать проекты между шардами (shards) при помощи команды rake. Эта функциональность не предполагается для частого использования, однако она может оказаться полезной в случаях, когда вы хотите протестировать новый шард или переместить часто используемый проект на хранилище с быстрым доступом. В данном релизе был введен ряд изменений направленных на повышение производительности — мерж-реквесты и их диффы стали еще быстрее! Ниже приведены графики, показывающие разницу в производительности после развертывания GitLab 8.11 RC2 на GitLab.com (падение в производительности попадает на развертывание). Время загрузки диффов для мерж-реквестов:  Количество выполненных SQL-запросов при отображении диффов:  Время, потраченное на выполнение SQL-запросов при отображении диффов:  Также значительно повысилась производительность конвейеров:  Ниже приведен детальный список проведенных улучшений и соответствующих мерж-реквестов: GitLab 8.11 поставляется с Mattermost 3.3, открытым аналогом Slack. В Mattermost 3.3 добавлены локализации на китайский, корейский и голландский языки, бот на Go,
возможность помечать (flag) посты, упоминания вида @here и многое другое. Кроме того, в этоу версию Mattermost вошли несколько security updates, поэтому мы настоятельно рекомендуем обновиться на нее. В GitLab теперь еть экспериментальная поддержка Redis Sentinel. Этот релиз включает в себя и многие другие улучшения, включая различные security fixes. Полный список изменений доступен в  Changelog. Обновление до GitLab 8.11 потребует даунтайма из-за миграций баз данных Даунтайм для сайта GitLab.com (самый крупный из известных нам инстансов GitLab) составил 15-30 минут. В зависимости от количества данных на вашем инстансе ваш даунтайм может быть меньше. Одна из миграций удаляет несколько столбцов в нескольких таблицах (и инстанс GitLab нужно свернуть, чтобы эти данные не пропали в процессе доступа к ним). Две другие миграции создают новые таблицы и наполняют их информацией на основе уже существующих в системе данных: в этом случае даунтайм нужен, чтобы добавляемые данные не поменялись в процессе работы миграции (и оставались неизменными, пока развертывание 8.11 не завершено полностью). Наконец, еще одна миграция добавляет два внешних ключа (foreign keys), и здесь даунтайм нужен для гарантии отсутствия одновременного доступа к изменяемым данным. С этим релизом мы обновили Ruby до версии 2.3. Для ручных установок мы настоятельно рекомендуем вам обновить Ruby до 2.3. Установки GitLab, сделанные через Omnibus, автоматически будут использовать Ruby 2.3. Поддержка Ruby 2.1 и 2.2 будет полностью прекращена в GitLab версии 8.13. Если вы обновились до 8.11 сразу после релиза и в процессе reconfigure получили ошибку undefined method merge! for nil:NilClass, то скачайте более новый пакет с младшей версией .1: 8.11.0-ce.1. Просто запустите apt-get update and apt-get install gitlab-ce / apt-get install gitlab-ee, и всё должно починиться само. Если у вас включена двухфакторная аутентификация и вы пытаетесь получить API-токен через метод /sessions или Resource Owner Password Credentials flow provided в OAuth2, то вы не сможете залогиниться. Для успешного логина в этих случаях вам нужно будет использовать Personal Access Token. Мы изменили структуру индексов Elasticsearch и теперь они используют взаимоотношения типа «родитель-ребенок». Это повышает производительность, но требует полной перестройки всех индексов Elasticsearch. После обновления до 8.11 вам надо будет вручную удалить старые индексы и построить новые. Для удаления старых индексов сделайте вот такой запрос к Elasticsearch: Для перестройки индексов выполните действия описанные в документации по интеграции с Elasticsearch Внимание Описанное выше применимо только если вы обновляетесь с предыдущей версии (8.10). Если вы обновляетесь с более ранних версий, проверьте разделы «Upgrade-барометр» для всех промежуточных версий. Если вы обновляетесь с версии GitLab, меньшей, чем 8.0 и при этом у вас включен CI, вам нужно сначала обновиться до 8.0. По умолчанию в процессе обновления все пакеты Omnibus будут остановлены, потом будут прогнаны все их миграции, и только потом они будут запущены снова. Это поведение не зависит от «размера» обновления. Изменить это поведение можно, создав файл /etc/gitlab/skip-auto-migrations. Если вы устанавливаете GitLab с «нуля», прочитайте соответствующий раздел: https://about.gitlab.com/installation/ Инструкции по обновлению: https://about.gitlab.com/update/ GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп. Подробную информацию можно посмотреть в описании GitLab EE. GitLab EE доступен только по подписке, подробности и цены можно посмотреть вот тут. Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах. P.S. Если будете обновляться, обновляйтесь сразу на 8.11.2 P.P.S. Над переводом работали chebureque, nick_volynkin и @sgnl_0 Smartprogrammer.ru