Несколько досок задач вместо одной (EE)

Теперь в каждом проекте GitLab Enterprise Edition может быть несколько досок задач.

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

Мы с нетерпением ждём ваших рассказов о том, какое применение вы найдёте доскам задач.

Создание новых задач непосредственно на доске задач

При просмотре доски задач вы можете быстро добавить ещё одну в любой список:

Разумеется, она сразу же получит соответствующие метки.

Редактор мерж-конфликтов.

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

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

Мы надеемся, это поможет вам за быть всю боль мерж-конфликтов как страшный сон.

Групповые метки

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

Чтобы её упростить, мы реализовали групповые метки (group labels). Они работают точно так же, как и обычные, но создаются и настраиваются один раз для группы проектов, после чего доступны в каждом проекте.

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

Возможность остановки Review Apps

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

Ссылки на развёрнутые версии кода

GitLab создаёт специальные ссылки (ref) на версии кода, которые в данный момент развёрнуты на каждом из ваших окружений (environments). Вам достаточно один раз настроить ваш локальный репозиторий, чтобы обновлять эти ссылки с помощью простого git fetch.

Конвейеры в просмотре коммитов

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

Улучшения Cycle Analytics

Изменено поведение Cycle Analytics — теперь проводятся замеры всей активности за определенный промежуток времени, а не только отправки в продакшен. Само собой, стадии staging и production показывают только то, что было отправлено в продакшен.

Назначение тикетов автору мерж-реквеста

Вы указали ссылки на определенные тикеты в своем коммите или мерж-реквесте, но не назначили их на себя или на автора мерж-реквеста? Теперь есть простой способ сделать это:

Ограничение видимости репозитория проекта

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

Слеш-команда /wip

Теперь можно использовать наши замечательные слэш-команды для быстрого изменения статуса мерж-реквеста с/на Work-In-Progress (WIP).

Просто введите /wip и подтвердите отправку вашего комментария или описания мерж-реквеста.

Отслеживание отладки CI

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

С другой стороны, из-за этого бывает сложно установить причину неправильного выполнения какой-либо задачи. В такой ситуации вы можете включить отслеживание отладки в .gitlab-ci.yml, эта опция доступна в GitLab Runner начиная с версии 1.7. Она включает трассировку shell, в результате чего в логи сборки добавляется информация о выполнении всех команд, присваивании значений всем переменным и т.д.

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

Для включения отслеживания отладки присвойте переменной `CI_DEBUG_TRACE значение true:

job1:
  variables:
    CI_DEBUG_TRACE: "true"

Более подробная информация в документе по отслеживанию отладки

Отключение операций Git в CI

Появилась возможность отключения операций Git для ускорения сборок, не требующих взаимодействия с репозиторием. Для этого нужно указать стратегию Git в файле .gitlab-ci.yml:

variables:
  GIT_STRATEGY: none

Более подробно о стратегиях Git в CI можно почитать в нашей документации

Дата развертывания в мерж-реквестах

Небольшое, но приятное нововведение — теперь дата развертывания указывается прямо в мерж-реквесте.

GitLab Runner

Также, вместе с GitLab 8.13 был выпущен GitLab Runner 1.7. Список самых интересных изменений:

• Добавлено использование Go 1.7 — добавляет поддержку Runner на Mac OS X Sierra !323
• Добавлена GIT_STRATEGY=none !332
• Добавлена поддержка OffPeak для автоскейлинга !345
• Введена переменная для включения режима трассировки shell в bash, cmd.exe и powershell.exe !339
• В первую очередь загружается конфиг InCluster, если загрузка неудачна — конфиг kubectl !327
• Godep: github.com/Sirupsen/logrus обновлен до версии 0.10.0 !344
• Добавлено использование git clone –no-checkout и git checkout –force !341
• Значение поля runner теперь переводится в нижний регистр для совместимости с ограничениями GCE !297
• Добавлена обработка before_script при выполнении команды exec !355
• Сборки больше не помечаются как неудавшиеся из-за ошибки кеширования !359
• Внесены улучшения в процедуру регистрации !356

Полный список изменений можно посмотреть в чейнджлоге Runner’а.

GitLab Mattermost

В GitLab 8.13 включен Mattermost — альтернатива Slack с открытым исходным кодом, доступная на вебе, десктопе и мобильных усторйствах и интеграцией более чем с 700 приложениями при помощи Zapier. В этом месяце добавлена интеграция с Slack, Gitter, XMPP и IRC. Mattermost теперь обновляется 6 раз в год; новые обновления добавляются в GitLab через месяц после их выхода.

Нововведения в API

В данный релиз включено несколько нововведений в API:

Одновременный коммит нескольких файлов

Благодаря MVP месяца Марку появилась возможность совершать через API коммит нескольких файлов одновременно.

Документация по API на эту тему

Интерфейс доски задач

Андре Гуэдэс (Andre Guedes) реализовал полноценный API для доски задач. Спасибо, Андре!

Информация о действиях пользователей

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

Документация на эту тему

Список видимых проектов

Благодаря Бену Бекелю (Ben Boeckel) появилась возможность просмотреть список всех видимых вам проектов через API.

Больше информации в документации по API

Изменения в производительности

Изменения в CE:

• Улучшена производительность отображения страницы group milestones: !6457
• Уменьшено количество выполняемых запросов при обработке ссылок Markdown: !6457 и !6545
• Sidekiq теперь использует пул связей при работе с кешем Rails: !6468 и !6657
• Уменьшено количество обновлений таблицы ci_runners, благодаря чему уменьшено количество обращений к базе данных: !6537
• Немного уменьшено количество выполняемых запросов при пуше коммитов: !6680
• Добавлен ежедневный предварительный подсчет рейтинга проектов для страницы trending projects, что повышает ее производительность: !6749
• Добавлена асинхронная загрузка diff’ов при создании нового мерж-реквеста: !5844
• При изменении timestamp’а последних изменений проекта более не используются временные ссылки (leases) Redis: !6678
• Секретный токен для gitlab-shell и API теперь хранится в памяти, а не читается с диска при каждом запросе API: !6599
• Уменьшено количество запросов, используемых при проверке политик проекта: !6442
• Worker, используемый для истекающих артефактов сборки, теперь эффективнее распределяет задачи и использует более эффективные запросы SQL: !6732
• Обновления мерж-реквестов с помощью пушей теперь используют специальный Sidekiq worker: !6767
• Хуки конвейера CI теперь обновляются асинхронно: !6824
• Метрики конвейера CI теперь обновляются с помощью Sidekiq worker: !6896
• Улучшена производительность и использование памяти загрузчика GitHub: !6552
• Оптимизировано получение URL для отрисовки эмодзи в обсуждениях.: !6848
• При создании проекта мы автоматически создаем соответствующую строку project_features вместо проверки этого (и создания строки при необходимости), когда бы мы ни запрашивали проект из базы данных. Это уменьшает количество запросов к базе данных, когда нам нужно вернуть проект из версии 2 в 1: !6908
• Коммиты конвейера CI обновляются только после создания конвейера вместо обновления каждого по-отдельности: !6986
• Длительности конвейера CI обновляются только в конце конвейера вместо обновления после каждого изменения состояния: !6987
• Обновление кэша проекта теперь происходит каждые 15 минут. Статистика может стать несвежей (например, подсчет коммитов), но существенно уменьшится нагрузка на диск: !7017
• Sidekiq теперь использует разные очереди для большого количества разных работников: !7006
• Задачи в конвейере CI распределяются умнее, предотвращая назначение нескольких задач с одними и теми же параметрами в одно и то же время: !7005
• Кэширование полей markdown в базе данных !6095

Изменения в EE:

• Данные об использовании GitLab теперь кэшируются: !779

Изменения в gitlab-shell:

• Отслеживание производительности Git теперь может быть включено с помощью переменной окружения: !91
• Улучшено перемещение репозиториев между шардами: !97 и !96

Изменения пакета Omnibus GitLab

• Jemalloc теперь используется как аллокатор памяти по умолчанию, что должно снизить объем используемой памяти.
• У пакетного NGINX теперь есть метод Status, включенный по умолчанию. Спасибо Luis Sagastume!
• Новые опции конфигураций добавлены в файл gitlab.rb

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

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

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

Этот релиз содержит значительное количество миграций, которые требуют даунтайма. Администраторы должны приготовиться минимум к 30 минутам простоя. Небольшие установки (например, с несколькими сотнями проектов) должны завершать процесс миграций за 5-10 минут.

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

Некоторые из миграций:

• добавляют внешние ключи в существующие таблицы
• перемещают задачи Sidekiq из одной очереди в другую
• удаляют повторяющиеся ярлыки (labels)
• устанавливают приоритеты ярлыков
• производят другие чистки данных

Очереди Sidekiq

Этот релиз внес несколько изменений в Sidekiq. Раньше GitLab использовал ограниченное количество очередей, которое было жестко определено в bin/background_jobs и в Omnibus GitLab. Начиная с версии 8.13 все названия используемых очередей находятся в config/sidekiq_queues.yml. Пользователям, использующим bin/background_jobs для запуска Sidekiq или Omnibus GitLab, больше не нужно ничего делать вручную. Пользователям, запускающим установку из исходников, может потребоваться внести изменения в настройки, чтобы удостовериться, что Sidekiq использует этот конфигурационный файл. Для этого им нужно убедиться, что Sidekiq запускается следующим образом:

sidekiq -C path/to/gitlab/config/sidekiq_queues.yml

Если вы используете кастомный файл конфигурации 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 с «нуля», прочитайте соответствующий раздел.

Обновление

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

Enterprise Edition

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

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

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