От идеи к производству

Своими последними релизами GitLab изменил подходы команд к разработке продуктов. Всего за несколько минут вы можете развернуть GitLab в планировщике контейнеров (container scheduler), добавить CI/CD с автоматически развернутыми review apps, использовать ChatOps и проанализировать время вашего цикла (cycle time). В версии 9.0 вы сможете просматривать ваши деплои на deploy boards и отслеживать производительность приложений с помощью Prometheus. Основываясь на нашем Мастер-Плане, GitLab 9.0 предоставляет огромный набор DevOps-инструментов для разработчиков. Давайте посмотрим, как он работает.

Юзабилити и дизайн

В версии 8.0, мы освежили интерфейс GitLab, изменив почти каждый элемент UI и значительно улучшив юзабилити (мы даже обновили логотип несколько месяцев назад.) С тех пор мы продолжаем инвестировать в дизайн, наращивая нашу команду UX дизайнеров и исследователей, которые с энтузиазмом работают над улучшением юзабилити, находят и лечат основные болевые точки во всех сферах от небольших твиков CSS до изменения главных потоков UX. В каждом релизе 8.x мы постепенно развивали дизайн. А в GitLab 9.0 мы достигли существенных успехов в упрощении нашей общей, групповой и проектной навигации. Это ключевое изменение, с помощью которого набор функций GitLab становится все более мощным.

В целях продолжения улучшения UX у нас появилась исследовательская группа (research panel), в которой вы можете повлиять на будущее GitLab. Присоединившись к этой группе, вы первыми опробуете новые фичи, и ваши мысли по поводу них мы учтем в улучшениях продукта.

Присоединяйтесь к нашей исследовательской группе.

Совместная цифровая работа (Digital Work)

GitLab помогает вам объединяться для совместной цифровой работы. Мы сделали множество изменений в задачах (issues), основе совместной работы в GitLab. Например, веса задач (8.3), связывание их с мерж-реквестами (8.3), перемещение задачи в другой проект (8.6), и мощный интерфейс фильтра и поиска (8.16). Также мы выпустили доски задач (issue boards) (8.11), предоставляющие простой механизм для управления потоком задач с использованием разных этапов («списков» (“lists”), на языке GitLab). GitLab 9.0 продолжает и дальше совершенствовать доски, улучшая интеграцию с майлстоунами.

Мы рады представить подгруппы в GitLab 9.0, еще один большой шаг в улучшении совместной работы в GitLab. Эта новая мощная парадигма групп в группах помогает совместной работе по принципам team-based и team-first даже в больших организациях с большим количеством разных отделов. Наша миссия — позволить каждому делать вклад. Версия 9.0 помогает упрощать процессы, где бы вы ни работали, поэтому и в самом деле каждый человек в вашей организации может сделать вклад в общую задачу.

Ревью и совместная работа над кодом

Мы продолжаем улучшать ревью и совместное написание кода в GitLab с версии 8.0, включая такие функции, как мерж после успешного выполнения конвейера (8.3), диффы (code diffs, 8.4, 8.5, 8.7, 8.10, 8.15), редактор конфликтов (8.11, 8.13), версии мерж-реквестов (8.12), блокировка мержа до решения дискуссий (8.14), переключение разрешений (8.16), так же как сквош и мерж (8.17). Многие эти и другие функции включают виджет мерж-реквеста. Поэтому в GitLab 9.0 мы поправили его дизайн, чтобы согласовать с многими существующими и будущими фичами, которые взаимодействуют с ним.

Непрерывная интеграция

Начиная с версии 8.0 в GitLab была добавлена непрерывная интеграция (continuous integration, CI). После этого в API была добавлена новая функциональность CI (8.4), а события конвейеров стали доступны через веб-хуки (8.11). Также была произведена интеграция конвейеров в мерж-реквесты (8.11, 8.17) и коммиты (8.13), к тому же было добавлено графическое отображение конвейеров (8.11). В каждом релизе начиная с 8.10 и до 8.17 добавлялись улучшения GitLab runner. Мы запустили review apps (8.12, 8.13, 8.14) и auto deploy (8.15) для автоматического развертывания кода в автоматически создаваемые среды. А с выходом GitLab 9.0 мы запускаем deploy boards, что позволит следить за развертыванием ваших приложений на различные серверы.

Анализ и мониторинг

GitLab предоставляет инструменты для анализа и мониторинга вашего кода и процесса разработки. В версии (8.3) было добавлено отображение вклада участников проекта в разработку, а также аналитика цикла разработки (8.12, 8.13, 8.14). Была добавлена функциональность учета времени (8.14, 8.16). В версиях 8.16 и 8.17 был добавлен open source Prometheus, благодаря чему появилась возможность мониторинга сервера, на котором запущен инстанс GitLab через консоль Prometheus. В GitLab 9.0 был добавлен интегрированный мониторинг на основе Prometheus, встроенный в пользовательский интерфейс GitLab.

Благодарности

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

В GitLab CE, который является open source проектом, сделано уже более 47000 коммитов, что более чем в два раза превышает количество коммитов в версии 8.1 — 20000. На данный момент более 1500 участников внесли свой вклад в развитие GitLab. Спасибо вам!

Рост

Наша команда тоже серьезно выросла за это время. На момент выхода версии 8.0 в GitLab работало менее 25 человек из семи стран. Сегодня нас больше 150 человек из 37 стран. Такой рост позволил нам выпускать три различные версии GitLab: Community Edition (CE), Enterprise Edition Starter (EES) и Enterprise Edition Premium (EEP).

Уникальная платформа

В последнее время, инструменты управления жизненным циклом приложения (application lifecycle management — ALM) развиваются в направлении единого интегрированного подхода. GitLab всецело поддерживает такой вектор развития и, как следствие, в данной версии функциональность мониторинга поставляется по умолчанию, как и планировалось. Отныне вы можете заниматься разработкой, написанием кода, сборкой, развертыванием и мониторингом вашего приложения прямо из GitLab.

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

Пользуйтесь версией 9.0 с удовольствием!

Зарегистрируйтесь, чтобы просмотреть презентацию релиза

Встречи по выходу GitLab 9.0

Митапы по поводу выхода GitLab 9.0 пройдут в Сан-Франциско, Денвере, Бостоне, Амстердаме, Лондоне и Новом Орлеане.

Присоединяйтесь!

MVP этого месяца — Jacopo Beschi.

Благодаря ему появилась возможность убирать у элемента списка todo ранее присвоенный статус ‘завершенный’, что позволяет вернуть todo-задачу, которую вы отметили завершённой по ошибке и, как следствие, повышает продуктивность разработки. Спасибо, Jacopo!

Подгруппы (CE, EE)

Использование GitLab всегда было самым простым способом совместной работы над кодом на всех этапах существования проекта, начиная с идеи и заканчивая релизом. Также от пользователей поступали запросы на реализацию совместной работы, основанной на иерархии команд разработчиков с отдельными репозиториями. В Gitlab 9.0 мы с радостью представляем новую версию групп GitLab, поддерживающую создание групп внутри групп, то есть «подгрупп».

Любая подгруппа на любом уровне иерархии является полноценной группой GitLab, которой может принадлежать несколько проектов (репозиториев). Таким образом, новая версия групп позволяет создавать иерархию вплоть до 20 уровней вложенности.

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

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

Более детальная документация по подгруппам

Deploy Boards (EEP)

GitLab поддерживает мощную систему CI/CD, в которой только для проектов на GitLab.com есть больше тысячи обработчиков (runners). Выполняемые на них конвейеры (pipelines) компилируют и собирают ПО, запускают автоматические тесты, создают review apps и даже могут проводить развертывание в staging и production. Ранее по результатам развертывания приходил отчет, в котором указывалось, было ли обновление среды успешным. Но что если требуется больше деталей? Или, скажем, единый интерфейс для просмотра информации по всем развертываниям во всех средах? Для крупных организаций ответы на эти вопросы становятся особенно важными.

С выходом GitLab 9.0 мы рады представить Deploy Boards для сред, использующих Kubernetes. Вкладка Pipelines -> Environments предоставляет единый интерфейс для просмотра информации о текущем состоянии и статусе развертывания для каждой среды, вплоть до каждого пода (pod). Разработчики и другие члены команды могут просматривать прогресс и состояние развертывания для каждого пода по отдельности в привычной среде разработки, не нуждаясь в доступе к Kubernetes.

В честь запуска Deploy Boards будут доступны в версии 9.0 бесплатно для пользователей Enterprise Edition Starter.

Документация по Deploy Boards

Экспорт задач (EES)

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

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

Более подробную информацию об экспорте задач можно найти здесь

Интегрированный мониторинг (CE, EE)

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

С выходом GitLab 9.0 мы с гордостью представляем первую систему мониторинга, полностью интегрированную в конвейеры CI/CD и репозиторий исходного кода. Отныне в тестовых средах разработки GitLab, таких как staging и review apps, используются те же технологии мониторинга, что и в итоговой «боевой» среде. Данная система реализована с использованием Prometheus.

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

Примите участие в обсуждении дальнейшего развития системы мониторинга GitLab здесь.

Документация об интеграции проектов с Prometheus

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

Как обычно, мы усердно работаем над повышением производительности GitLab. В версию 9.0 внесен целый ряд изменений направленных на значительное ускорение работы системы. В GitLab EE 9.0 в Elasticsearch (ES) внесен ряд исправлений, а также поддержка версии ES 5.1. Следуя философии “cloud native”, мы добавили поддержку AWS-hosted и HTTPS кластеров Elasticsearch. Улучшения в процессе первичной индексации ускорят работу крупномасштабных проектов на GitLab EE. Кроме того, ряд небольших изменений был внесен в процесс индексации репозиториев.

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

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

Известно ли вам, что GitLab.com это «всего лишь» крупномасштабная имплементация GitLab EE с сотнями тысяч пользователей? Это позволяет оценить масштаб, на котором можно работать с GitLab EE, а вышеупомянутые улучшения производительности заметно повысят скорость и надежность работы GitLab.com.

Transaction timings dropping significantly for issues dashboard

Transaction timings dropping significantly for merge requests dashboard

Распределение нагрузки на базы данных (EE)

Балансировка загрузки запросов к базам данных позволяет рассредоточить объем запросов и нагрузку на серверы. Как правило, для этого требуется использование стороннего ПО, например pgpool. Начиная с версии 9.0 GitLab Enterprise Edition поддерживает распределение запросов при использовании PostgreSQL.

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

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

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

Для решения этой проблемы используется подход “sticky sessions”: когда пользователь инициирует запись в основную базу данных, сессия этого пользователя продолжает использовать именно основную базу. Это продолжается до истечения таймаута (30 секунд), либо до того момента, когда записываемые данные становятся доступными на всех вторичных базах.

Больше информации о настройке балансировщика базы данных есть в документации “Database Load Balancing”.

Обновленная навигация (CE, EE)

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

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

Мы перегруппировали (а в некоторых случаях объединили и переименовали) вкладки первого и второго уровня в меню навигации. Вкладка активностей теперь вложена во вкладку проекта. Главные вкладки репозитория, задач, мерж-реквестов и конвейеров теперь расположены соответственно слева направо, по смыслу «от идеи к производству». Вкладки второго уровня из вкладки Graph мы перегруппировали и перенесли в другие места. Мы придумывали, где каждый пункт меню должен находиться, используя данные аналитики и ваших пожеланий. Узнайте подробнее о деталях изменения.

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

В 9.0 мы упростили настройки конфигурации вида проекта, поэтому теперь вы можете выбрать, что показывать на «домашней странице» каждого проекта: список файлов и README или текущую активность. (Это настройка профиля, применяемая ко всем проектам, которые вы просматриваете.) Первая опция используется по умолчанию. Раньше по умолчанию показывался только README, но мы хотели чего-то, что помогло бы и новым, и существующим пользователям. Поэтому мы изучили обратную связь и пользовательские исследования и остановились на этом варианте.

Еще мы вернули возможность быстро создавать новые проекты, просто нажав кнопку + справа вверху.

Изменение порядка задач в списке доски (CE, EE)

Issue Boards — отличный способ управлять задачами, перемещающимся по разным стадиям («спискам» (“lists”) в GitLab), чтобы быстро перейти от идеи к производству. Но пользователи часто хотят изменять порядок или приоритет задач даже внутри одного списка. В версии 9.0 вы можете изменять порядок задач в списке доски задач, воспользовавшись простым перетаскиванием.

Узнайте больше об Issue Boards для Community Edition в нашей документации.

Доски с майлстоунами (EES)

Доска задач GitLab позволяет вам управлять группами задач в одном майлстоуне (milestone), но требует выбирать связанный фильтр майлстоунов каждый раз, когда вы к нему переходите. В GitLab 9.0 EES вы сможете создавать доску задач, связанную с конкретным майлстоуном. Это позволит вам создавать уникальные доски для отдельных майлстоунов.

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

Больше об Issue Boards для Enterprise Edition в нашей документации.

API v4 (CE, EE)

Наш API — отличное средство для автоматизации задач и управления GitLab. Мы постоянно улучшаем наш API, чтобы он поддерживал новые фичи, которые мы добавляем каждый месяц, чтобы сделать GitLab лучшей средой разработки от начала до завершения проекта.

Постоянные итерации привели к нескольким несоответствиям в существующем API. В этом релизе мы представляем четвертую версию нашего API. Мы постарались сделать его более консистентным и соответствующим стандарту RESTful API.

Мы продолжим поддерживать третью версию API только до августа 2017 и предлагаем вам внести все необходимые изменения в приложения, использующие эту версию.

Посмотрите изменения 4 версии, чтобы узнать, что стало другим

Аварийное восстановление (альфа-версия) (EEP)

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

С версии GitLab 8.5, GitLab поставляется с Geo. Это фича, которая позволяет заводить один или несколько дополнительных инстансов GitLab, которые зеркалируют (mirror) ваш главный инстанс. Основная цель Geo — кардинально ускорить клонирование и получение (git fetch) проектов на больших расстояниях. С этим сценарием Geo справляется отлично, но у нее есть один недостаток, из-за которого мы не используем эту технологию для полной поддержки аварийного восстановления: файлы, сохраненные на диске, не реплицируются.

Мы активно работаем над исправлением этого недостатка, а в GitLab 9.0 мы выпускаем первый этап поддержки сценариев аварийного восстановления. Несколько важных изменений Geo появилось уже в этом релизе:

• Если вы используете LFS, объекты LFS будут автоматически дублироваться в дополнительные ноды (мерж-реквест).
• Все загрузки файлов теперь записываются в базу данных (мерж-реквест). Это позволит нам реплицировать эти файлы в последующей итерации.
• Появился новый процесс автоматического заполнения репозиториев (мерж-реквест).
• Теперь вы можете отключить дополнительный нод в пользовательском интерфейсе.
• А пока все описанные выше фичи есть только в альфа-версии, главная фича Geo, используемая для клонирования и получения проектов на больших расстояниях, по-прежнему пригодна для коммерческого использования (production-ready).

Документация расскажет вам, как включить альфа-версию аварийного восстановления.

Аварийное восстановление доступно всем клиентам Enterprise Edition Premium как часть GitLab Geo.

На заметку: благодаря обновлению PostgreSQL’s, произошедшему в GitLab 9.0, GitLab Geo 8.x стал несовместим с GitLab Geo 9.0, поэтому обновляться нужно вручную. Если вы уже используете Geo, прочитайте инструкции для обновления перед обновлением до GitLab 9.0.

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

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