Мы путешествуем по миру и очень рады встречам с нашими пользователями. В этом месяце мы с гордостью хотим вам представить множество нововведений, о которых вы просили нас как лично, так и через наш трекер задач. Теперь можно создавать несколько досок задач (issue boards), а находясь на странице доски — быстро заводить новые задачи. Жизнь мерж-конфликтов стала ещё тяжелее и скоротечнее, потому что теперь их можно разрешать непосредственно в GitLab. Улучшенная система Cycle Analytics позволяет ещё проще следить за тем, какая версия кода выполняется в каждом из окружений (environments), а также предоставляет вам моментальную обратную связь. Званием MVP этого месяца награждается Марк Зигфридт (Marc Siegfriedt) за его вклад в создание точки входа (endpoint) API для коммита нескольких файлов сразу. Марк проявил терпение и упорство в работе над этим сложным мерж-реквестом. Спасибо, Марк! Теперь в каждом проекте GitLab Enterprise Edition может быть несколько досок задач.  Это позволяет вам управлять несколькими рабочими процессами, так как метки на задачах обновляются синхронно на всех досках. Например, у вас есть доска задач всей компании и отдельная — для команды дизайнеров. Когда команда дизайнеров выполняет свою часть задачи и передаёт задачу команде фронтенда, обновляются обе доски. Мы с нетерпением ждём ваших рассказов о том, какое применение вы найдёте доскам задач. При просмотре доски задач вы можете быстро добавить ещё одну в любой список:  Разумеется, она сразу же получит соответствующие метки. В GitLab 8.11 появилось разрешение мерж-конфликтов, позволяющее при разрешении конфликта выбирать между вариантом из текущей ветки и из той, которая мержится в текущую. В GitLab 8.13 появился новый инструмент разрешения конфликтов. Теперь вы можете редактировать конфликтующие изменения прямо в GitLab. Другими словами, почти любые конфликты можно разрешить не покидая страницы браузера.  Мы надеемся, это поможет вам за быть всю боль мерж-конфликтов как страшный сон. Когда у вас есть одна организация и несколько проектов, часто бывает необходимо создавать одинаковые метки с одинаковой расстановкой приоритетов сразу на нескольких досках задач. Это довольно скучная работа. Чтобы её упростить, мы реализовали групповые метки (group labels). Они работают точно так же, как и обычные, но создаются и настраиваются один раз для группы проектов, после чего доступны в каждом проекте.  В данный момент создавать групповые метки можно только со страницы вашей группы. В будущем мы реализуем возможность преобразовывать уже существующие метки проекта в групповые. Review Apps позволяют вам развернуть код любого коммита в полноценном работающем окружении для ревью и тестирования. Теперь, когда такое окружение перестанет быть вам нужным, вы сможете остановить его непосредственно через интерфейс GitLab.  GitLab создаёт специальные ссылки (ref) на версии кода, которые в данный момент развёрнуты на каждом из ваших окружений (environments). Вам достаточно один раз настроить ваш локальный репозиторий, чтобы обновлять эти ссылки с помощью простого git fetch. Теперь на странице просмотра коммитов мы показываем соответствующие конвейеры, что позволяет сразу увидеть, что происходило с каждым из коммитов.  Изменено поведение Cycle Analytics — теперь проводятся замеры всей активности за определенный промежуток времени, а не только отправки в продакшен. Само собой, стадии staging и production показывают только то, что было отправлено в продакшен. Вы указали ссылки на определенные тикеты в своем коммите или мерж-реквесте, но не назначили их на себя или на автора мерж-реквеста? Теперь есть простой способ сделать это:  Появилась возможность ограничения доступа к репозиторию проекта, вдобавок к уже существующей функциональности ограничения доступа к тикетам (issues) и фрагментам кода (snippets). Теперь можно убрать доступ к репозиторию вообще для всех, либо оставить доступ исключительно для членов команды.  Теперь можно использовать наши замечательные слэш-команды для быстрого изменения статуса мерж-реквеста с/на Work-In-Progress (WIP). Просто введите /wip и подтвердите отправку вашего комментария или описания мерж-реквеста.  По умолчанию GitLab Runner не отображает большую часть информации о процессе работы с задачами. Такой подход препятствует избыточности логов сборки, а также попаданию в них секретной информации, если только она не выводится в консоль с помощью скрипта. С другой стороны, из-за этого бывает сложно установить причину неправильного выполнения какой-либо задачи. В такой ситуации вы можете включить отслеживание отладки в .gitlab-ci.yml, эта опция доступна в GitLab Runner начиная с версии 1.7. Она включает трассировку shell, в результате чего в логи сборки добавляется информация о выполнении всех команд, присваивании значений всем переменным и т.д. Перед подключением данной опции убедитесь, что логи сборки могут просматривать только члены команды. Также, не забудьте удалить все сгенерированные логи перед тем, как снова откроете видимость для всех. Для включения отслеживания отладки присвойте переменной `CI_DEBUG_TRACE значение true: Появилась возможность отключения операций Git для ускорения сборок, не требующих взаимодействия с репозиторием. Для этого нужно указать стратегию Git в файле .gitlab-ci.yml: Небольшое, но приятное нововведение — теперь дата развертывания указывается прямо в мерж-реквесте.  Также, вместе с GitLab 8.13 был выпущен GitLab Runner 1.7. Список самых интересных изменений: Полный список изменений можно посмотреть в чейнджлоге Runner’а. В GitLab 8.13 включен Mattermost — альтернатива Slack с открытым исходным кодом, доступная на вебе, десктопе и мобильных усторйствах и интеграцией более чем с 700 приложениями при помощи Zapier. В этом месяце добавлена интеграция с Slack, Gitter, XMPP и IRC. Mattermost теперь обновляется 6 раз в год; новые обновления добавляются в GitLab через месяц после их выхода. В данный релиз включено несколько нововведений в API: Благодаря MVP месяца Марку появилась возможность совершать через API коммит нескольких файлов одновременно. Андре Гуэдэс (Andre Guedes) реализовал полноценный API для доски задач. Спасибо, Андре! С помощью API теперь можно получить информацию об изменениях, внесенных в проект определенным пользователем. Благодаря Бену Бекелю (Ben Boeckel) появилась возможность просмотреть список всех видимых вам проектов через API. Изменения в CE: Изменения в EE: Изменения в gitlab-shell: В этом релизе много других изменений, включая различные исправления безопасности. Чтобы посмотреть все изменения, обратитесь к changelog. Этот релиз содержит значительное количество миграций, которые требуют даунтайма. Администраторы должны приготовиться минимум к 30 минутам простоя. Небольшие установки (например, с несколькими сотнями проектов) должны завершать процесс миграций за 5-10 минут. Помните, что эти оценки времени примерные и могут отличаться в зависимости от вашей ситуации. Некоторые из миграций: Этот релиз внес несколько изменений в Sidekiq. Раньше GitLab использовал ограниченное количество очередей, которое было жестко определено в bin/background_jobs и в Omnibus GitLab. Начиная с версии 8.13 все названия используемых очередей находятся в config/sidekiq_queues.yml. Пользователям, использующим bin/background_jobs для запуска Sidekiq или Omnibus GitLab, больше не нужно ничего делать вручную. Пользователям, запускающим установку из исходников, может потребоваться внести изменения в настройки, чтобы удостовериться, что Sidekiq использует этот конфигурационный файл. Для этого им нужно убедиться, что Sidekiq запускается следующим образом: Если вы используете кастомный файл конфигурации Sidekiq, вам нужно добавить содержание sidekiq_queues.yml в этот файл (и поддерживать его актуальным) или использовать sidekiq_queues.yml и определить кастомные настройки с помощью CLI (command line interface) для sidekiq. Этот файл конфигурации также определяет вес каждой очереди. Нагрузка на Redis немного увеличится, но Sidekiq теперь более справедливо распределяет работу вместо обработки очередей по порядку. Названия и приоритеты очередей могут быть настроены пользователем. Мы предполагаем, что вы обновляетесь с последней версии. Если это не так, ознакомьтесь с барометрами обновлений промежуточных версий, которые вы пропускаете. Если вы обновляетесь с GitLab версии до 8.0 и у вас подключена CI, вам следует сначала обновиться до GitLab 8.0 Пожалуйста, помните, что исходные пакеты Omnibus остановятся, запустят миграции и запустятся снова вне зависимости от того, насколько «большое» или «маленькое» получится обновление. Чтобы изменить это поведение, добавьте файл /etc/gitlab/skip-auto-migrations. Если вы устанавливаете GitLab с «нуля», прочитайте соответствующий раздел. Следите за нашими обновлениями. GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп. Подробную информацию можно посмотреть в описании GitLab EE. GitLab EE доступен только по подписке. Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах. Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru, над переводом работали nick_volynkin, rishavant и sgnl_05. Smartprogrammer.ru