GitLab Issues Functionalities
Please read through the GitLab Issue Documentation for an overview on GitLab Issues.
Issues Functionalities
The image bellow illustrates how an issue looks like:
You can find all the information on that issue on one screen.
Issue screen
An issue starts with its status (open or closed), followed by its author, and includes many other functionalities, numbered on the image above to explain what they mean, one by one.
Many of the elements of the issue screen refresh automatically, such as the title and description, when they are changed by another user. Comments and system notes also appear automatically in response to various actions and content updates.
1. New Issue, close issue, edit
2. Todos
3. Assignee
Whenever someone starts to work on an issue, it can be assigned to that person. The assignee can be changed as much as needed. The idea is that the assignee is responsible for that issue until it’s reassigned to someone else to take it from there.
Tip: if a user is not member of that project, it can only be assigned to them if they created the issue themselves.
3.1. Multiple Assignees (EES/EEP)
Issue Weights are only available in GitLab Enterprise Edition.
Often multiple people likely work on the same issue together, which can especially be difficult to track in large teams where there is shared ownership of an issue.
In GitLab Enterprise Edition, you can also select multiple assignees to an issue.
4. Milestone
5. Time Tracking (EES/EEP)
This feature is available only in GitLab Enterprise Edition.
Note: both estimate and spend times are set via GitLab Quick Actions.
6. Due date
When you work on a tight schedule, and it’s important to have a way to setup a deadline for implementations and for solving problems. This can be facilitated by the due date). Due dates can be changed as many times as needed.
7. Labels
Categorize issues by giving them labels. They help to organize team’s workflows, once they enable you to work with the GitLab Issue Board.
Group Labels, which allow you to use the same labels per group of projects, can be also given to issues. They work exactly the same, but they are immediately available to all projects in the group.
Tip: if the label doesn’t exist yet, when you click Edit, it opens a dropdown menu from which you can select Create new label.
8. Weight (EES/EEP)
Issue Weights are only available in GitLab Enterprise Edition.
9. Participants
10. Notifications
11. Reference
12. Title and description
13. @mentions
To change your notification settings navigate to Profile Settings > Notifications > Global notification level and choose your preferences from the dropdown menu.
Tip: Avoid mentioning @all in issues and merge requests, as it sends an email notification to all the members of that project’s group, which can be interpreted as spam.
14. Related Merge Requests
15. Award emoji
Tip: Posting «+1» as comments in threads spam all participants of that issue. Awarding an emoji is a way to let them know you like it without spamming them.
16. Thread
17. Comment, start a discusion, or comment and close
Once you wrote your comment, you can either:
Введение в непрерывную поставку (CD) при помощи GitLab
Данный туториал позволит вам быстро прочувствовать как происходит командная работа с использованием GitLab. В целом, начать практиковать DevOps/CD с GitLab проще чем с использованием других продуктов потому что GitLab — это решение «всё в одном».
В процессе этого туториала мы
Желательны но необязательны базовые знания
Время от времени я буду просить вас что-то сделать. Такие моменты помечены значком «!«. Пожалуйста выполняйте действия по мере чтения текста чтобы получить от данного туториала наибольшую пользу.
В оригинале места где требовалось что-то сделать были помечены эмодзи «молоток и гаечный ключ». Так как редактор habr’а вырезает эмодзи, я заменил эти эмодзи на «!«.
Трудно переводить на русский вещи, которые даже русскоязычные программисты между собой называют по-английски. Я постарался литературно переводить термины для которых есть общепринятые переводы и не переводить остальные. Например, мы будем использовать словечки вроде «чекбокс» и «коммитить», а названия разных штук в GitLab останутся на английском, как есть.
Введение и знакомство с проектом
В качестве «подопытного кролика» мы будем использовать чуть модифицированный шаблонный проект, созданный утилитой create-react-app.
Почему React? Во-первых, это самая распространённая UI-библиотека на JavaScript, и многие читатели знакомы с ней. Во-вторых create-react-app даёт нам осмысленные стадии компиляции и тестирования которые уже реализованы за нас.
! Теперь давайте клонируем репозиторий с кодом с которым мы будем работать.
! Перейдите в каталог локального репозитория
Должна отобразиться стандартная стартовая страница create-react-app.
Вы можете вместо этого этапа просто создать новое приложение при помощи create-react-app, но версия в репозитории содержит некоторые правки, и версии пакетов в коде в репозитории я тестировал.
! Установите npm пакеты локально, выполнив
Используйте npm ci если при выполнении npm install произойдёт ошибка
! Попробуйте «собрать» проект
! Затем запустите тесты
! Осталось осуществить «развёртывание», но чтобы не засорять туториал инструкциями по установке веб-сервера, давайте просто запустим отладочный веб-сервер чтобы увидеть как выглядит наше веб приложение выглядит в браузере.
Всё это, а также многое другое, поддерживается GitLab. Платная версия предлагает больше возможностей, но для наших целей нам хватит и бесплатной версии доступной на GitLab.com.
GitLab выделяется на общем фоне отсутствием ограничений на использование собственных job runners, однако некоторые довольно базовые «управленческие» и «корпоративные» фичи GitLab вроде обязательного утверждения merge request’ов входят в платные версии. Проектам с открытым кодом все фичи GitLab доступны бесплатно.
️ Базовая настройка управления проектом на GitLab.com
В этой части мы создадим сам проект в GitLab и задачи над которыми будем работать в дальнейшем, а также настроим Kanban-доску для визуализации состояния проекта.
Создание проекта в GitLab
Мы будем использовать GitLab.com в качестве инсталляции GitLab чтобы избежать хлопот по установке и настройке локальной версии.
! Если у вас ещё нет учётной записи на GitLab.com, зайдите на https://gitlab.com и заведите её.
GitLab позволяет нам создать проект просто выполнив push в удалённый репозиторий.
! Воспользуемся для этого следующей командой:
тут — ваше имя пользователя на GitLab.com.
Эта команда создаст приватный проект с именем gitlab-cd-react внутри вашей учётной записи на GitLab.com.
Далее мы настроим канбан-доску, а заодно создадим несколько задач чтобы было вокруг чего строить дальнейшую работу и о чём собирать статистику.
️ Создание задач и настройка доски
Давайте начнём с создания задачи.
! Кликните Issues в левом меню, затем нажмите одну из кнопок New Issue в основной области. Откроется форма создания задачи. Укажите в качестве заголовка «Создать задания для туториала».
В описании укажите следующий текст
Да, именно эти вещи мы и будем делать в дальнейшем. Оставьте остальные значения по умолчанию. Нажмите кнопку Submit issue.
Обратите внимание, что список с пробелами в квадратных скобках вначале элементов был распознан как чеклист, а отдельные его элементы как задачи. GitLab, как и многие другие платформы, использует Markdown в качестве языка разметки.
! Назначьте задачу Создать задания для туториала на себя. Для этого нажмите ссылку Edit в панели с надписью 0 Assignees справа на странице редактирования задачи.
Поздравляю, теперь вы — исполнитель. На самом деле на этом этапе задача может быть назначена любому члену команды но т.к. по сути ничего не изменится, мы не будем плодить пользователей.
! Давайте теперь на самом деле создадим все задачи, перечисленные в описании нашей первой задачи. Укажите только заголовки, остальные поля оставьте по умолчанию. Вы можете «ставить галочки» в описании задачи Создать задания для туториала как по мере создания задач, так и все сразу когда закончите.
Существуют разные способы создавать задачи, при создании задач по списку найдите и используйте хотя бы 3 разных способа. В итоге у вас должно получиться 6 задач.
Наш процесс работы
Под процессом работы(workflow) обычно подразумевается порядок этапов, которые задача проходит для того чтобы считаться выполненной. В Continuuos Delivery, Kanban и DevOps задача движется через некую последовательности состояний либо вперёд, либо может быть возвращена на один из предыдущих этапов.
Это подразумевает линеаризованные value streams. Про value streams можно почитать тут. Превращение порой затейливой диаграммы переходов в последовательность состояний является иногда очень сложной управленческой задачей, решение которой выходит за границы этой статьи.
Мы будем использовать простую последовательность состояний
Вначале задача оказывается в состоянии Open. Затем она затягивается(pull) в работу разработчикам в стадию Dev. После того, как работа завершена, происходит передача задачи в стадию Dev: done.
Зачем нам нужна эта дополнительная стадия? Дело в том что в Lean, на котором основаны все методологии типа CD, Kanban и DevOps, следующий этап(work center) затягивает задачи когда он готов в отличие от методологий где задачи передаются в следующий этап предыдущим. Это позволяет отслеживать задачи которые находятся в стадии ожидания, а накопление задач в стадии ожидания позволяет нам понять, где в нашем «конвейере» «бутылочное горлышко».
Итак, затем задача затягивается в этап QA где работают специалисты по качеству и автотесты, а «выпускники» QA считаются настолько хорошими что развёртываются непосредственно на продуктив.
«Ну так же не бывает, это же чих-пых — и в продакшн, должны же быть другие среды типа Staging в процессе!» — скажете вы. Я совершенно согласен, но тут мы используем максимально простой в реализации и для понимания конвейер чтобы меньше отвлекаться от GitLab и не закопаться где-нибудь в дебрях Kubernetes.
️ Настройка меток
Для организации задач GitLab использует метки(labels). Они как теги и позволяют искать, фильтровать и отображать задачи в разных местах в зависимости от наличия той или иной метки. Давайте заведём сами метки
Названия меток тут полностью произвольные и никакого особого смысла с точки зрения GitLab в них нет.
! Когда закончите, назначьте задачу Создать метки статус Closed.
Теперь всё готово для настройки Kanban-доски.
Настройка доски
В GitLab есть Kanban-доски. Они позволяют отображать разные задачи в соответствии с их метками. Несмотря на название они могут быть использованы не только для реализации Kanban, но и Scrum а также других методологий. У нас же уже создана задача для этого.
! Назначьте эту задачу на себя.
Если вы создали их в другом порядке, вы можете изменить порядок, перетаскивая списки «за заголовки».
Таким образом мы указываем что начали работать над этой задаче. Обратите внимание что у задачи появилась новая метка Dev.
! Так как всю работу мы уже сделали, переведите задачу в столбец Dev: done.
Мы приближаемся к стадии QA. Постарайтесь внутренне ощутить себя тестировщиком, подумайте какие разработчики неблагонадёжные люди, и, опционально, разберите при помощи отвёртки небольшой бытовой прибор.
! Затем переведите задачу в стадию QA. Тут можете несколько раз поперетаскивать задачу из столбца в столбец туда-сюда. Кстати, такие приключения порой и происходят с задачами на данном этапе. В процессе у задачи будет появляться метка нового столбца и исчезать метка предыдущего столбца. В конце концов оставьте задачу в столбце Closed и обратите внимание что в результате этого действия она была закрыта.
Есть ещё один полезный интерфейс — To-Do List(в меню рядом с меню логина есть подменю). Это список действий, которые по тем или иным причинам ожидается от вас. Мы не будем останавливаться на нём подробно, но я рекомендую заглядывать в него в процессе туториала время от времени чтобы составить представление о том как эта штука работает.
Конвейер непрерывной поставки
В этой секции мы реализуем непрерывную поставку(Continuous Delivery) средствами GitLab.
️ Построение конвейера непрерывной поставки в GitLab
Для того чтобы на самом деле выполнять код задач конвейеров, GitLab.com использует общие агенты (shared runners) которые реализуют docker executors. Если вы зарегистрируете свои собственные агенты, вам будет доступна куда большая гибкость в выборе сред сборки.
Давайте теперь сконструируем наш конвейер.
! Назначьте issue Создать конвейер непрерывной поставки и переведите его в статус Dev.
Формат, который использует GitLab для определения конвейеров сборки — один из самых простых и интуитивно понятных в отрасли.
Чтобы получить нужный нам конвейер чуть модифицируем этот файл.
image задаёт какой образ docker будет использован для выполнения jobs сборки. По умолчанию GitLab использует Docker Hub, но это можно настроить. Нам понадобится образ с предустановленным Node.js.
! Укажите
before_script и after_script выполняются перед и после каждой задачи соответственно. В процессе выполнения задач, мы будем использовать модули Node.js.
! Организуем кэширование модулей для того чтобы не скачивать модули каждый раз из интернета.
after_script нам в этом туториале не понадобится.
! Изменим команды чтобы действительно осуществлять сборку:
Обратим теперь внимание на кусок кода для этапа stage: test
Перейдём к части связанной напрямую с развёртыванием.
Эта часть обычно завязана на специфику среды в которую осуществляется развёртывание и потому технически сложна. GitLab поддерживает развёртывание в Kubernetes с минимальными усилиями по настройке. Альтернативой является реализация логики развёртывания в другую среду своими силами. Оставим технические детали этого процесса для будущих статей. Фокус данной статьи на объяснении основ работы с GitLab, поэтому мы прибегнем к хитрости, а точнее используем то обстоятельство что наше приложение на React технически является статическим вебсайтом и развернём его на GitLab Pages, которые доступны любому у кого есть учётная запись на GitLab.com.
! Заменим job deploy1 на этот код.
Мы переименовали deploy1 в pages потому что GitLab именно по названию задачи понимает что требуется развернуть файлы доступные этой задаче в GitLab Pages.
Далее делаем 2 вещи.
Завершим на этом работу над нашим конвейером.
! Переведите задачу Создать конвейер непрерывной поставки в стадию Dev: done.
Проведём несколько циклов работы с GitLab Flow
Git — очень гибкая система контроля версий кода и использовать его можно очень по-разному. Если каждый член команды использует Git по-своему, возникает путаница когда трудно понять логику действий других людей из истории изменений, и никто не понимает что ожидать от других. Об измерении производительности в такой ситуации и говорить не приходится. Для того чтобы такая путаница не возникала участники команды обычно договариваются о единых правила работы с Git, такая договорённость и называется Git workflow.
Чтобы изучить реализацию GitLab Flow в GitLab мы сделаем эти вещи:
Процесс работы с Git
Если коротко, то GitLab Flow состоит в том что
На самом деле для реализации CD нам годится любой процесс работы с Git который поддерживает trunk based development, и мы могли бы реализовать любой такой процесс при помощи GitLab. Однако по той причине, что GitLab рекомендует использовать GitLab Flow и для того чтобы не усложнять наш сценарий, мы его и используем.
Уровни доступа в GitLab
Существует разные уровни доступа, в порядке понижения полномочий.
Merge requests
Merge requests — основной способ внесения изменений в код при использовании GitLab. Изменения вносятся в код, затем автором изменений создаётся merge request, который затем обсуждается, в котором происходит code review. Merge request в результате принимается, отправляется на доработку или отклоняется.
! Переведите задачу Создать конвейер непрерывной поставки в стадию QA.
Да, вот так мы будем тестировать наш конвейер, но вы должны тестировать на реальных проектах более ответственно. Не делайте как я делаю, делайте как я говорю.
Наше приложение бесполезно. В этом нет ничего необычного, ведь в интернете много бесполезных приложений. Чтобы выйти на новый уровень, давайте сделаем наше приложение токсичным. Существуют 2 фичи, которые являются проверенным способом достичь этого.
В качестве Commit message укажите, например, «Add React imports». В качестве Target branch оставьте master и нажмите Commit changes.
! Измените Allowed to push на No one.
Соответствующий участок кода должен теперь выглядеть примерно так
Укажите «Add the annoying popup» в качестве commit message.
Вы увидите что вам предлагается добавить коммит в некую ветвь и в уже автоматически сгенерировано некоторое имя ветви. Мы в будущем заменим это имя на более осмысленное и соответствующее нашему процессу работы с Git, но пока давайте проведём небольшой эксперимент.
! Замените предлагаемое имя на master и нажмите Commit changes.
Нажмите Submit merge request
После создания merge request’а, ы окажетесь его на странице. Давайте изучим эту страницу. В основной области мы видим следующее.
Для бесплатных подписок есть только возможность «совещательного» согласования merge request’а, в платных версиях есть возможность сделать согласование необходимым.
Если вы переключитесь на вкладку Changes, вы можете посмотреть, какие изменения в код планируется внести. Здесь же вы можете создать комментарий, который будет ссылаться на строку кода.
Кстати, merge requests также поддерживают метки, которые вы можете использовать чтобы было проще находить нужные.
К этому моменту работа конвейера уже должна завершиться и… тесты завершены неуспешно. В нашем конкретном случае это потому что мы использовали window.alert который является чисто браузерным объектом и наши выполняемые в среде Node.js юнит-тесты не имеют к нему доступа.
В случае непрерывной поставки требуется очень хороший набор автоматических тестов потому что именно на них переложена почти вся, а в случае непрерывного развёртывания(Continuous Deployment) — вся, ответственность за контроль качества. Поддержание такого набора тестов в актуальном состоянии — главная технический вызов в реализации таких методологий.
! Давайте вернёмся в merge request Add the annoying popup и нажмём кнопку Merge и примем изменения в код. Оставьте чекбокс Delete source branch установленным.
При использовании GitLab Flow feature branches традиционно удаляют. Это позволяет избежать замусоривания системы уже неактуальными ветвями и создавать ветвь с тем же именем в случае отправки задачи на доработку.
При создании merge request’а таким образом задача будет закрыта автоматически как только мы сольём код в основную ветвь.
Добавим функцию оповещений в наш вебсайт чтобы он выглядел современно.
после ранее добавленной строчки
! Нажмите кнопку Commit в левой нижней части. Вы увидите интерфейс коммита, укажите в качестве commit message «Add the notifications users want». Оставьте всё остальное по умолчанию и нажмите кнопку Commit.
! Перейдите в merge request, например, используя подменю в верхней правой части экрана рядом с меню логина.Нажмите кнопку Mark as ready в верхней правой части формы merge request’а. Нажмите кнопку Merge или Merge when pipeline succeeds в зависимости от того завершился ли уже конвейер.
! Откройте наш тестовый вебсайт и убедитесь что новые «фичи» работают, и наша страница ощущается как большинство современных сайтов в интернете.
! Если с сайтом всё хорошо, перетащите задачу Создать конвейер непрерывной поставки в стадию Closed на доске.
Итак, мы провели несколько полных циклов работы и теперь можем изучить метрики, которые GitLab собрал в процессе работы.
Метрики CI/CD в GitLab
В процессе командной работы полезно собирать статистику чтобы понимать повышается ли продуктивность или падает. Способы оценки производительности могут быть совсем разными в зависимости от характера работы и типа проекта или продукта.
Например, веб-студия может иметь «типовые» задачи типа отрисовки макета в рамках стандартного пакета услуг, предлагаемого клиенту. Agile стартап же может находиться в стадии когда концепция продукта меняется вместе с растущим пониманием потребностей клиента и рынка, и задачи могут быть трудно предсказуемы и часто уникальны. Вместе с тем, можно выделить чисто технические показатели производительности вроде одного из основных для DevOps времени вывода новой фичи на рынок (time to market, TTM) или просто длительности той или иной стадии. Отслеживать динамику таких показателей может быть очень полезно: за достаточно длительный период времени это позволяет понять как изменяется производительность.
Хорошей новостью является то что GitLab имеет функционал сбора этой статистики. Давайте с этим функционалом познакомимся.
! Кликните на Analytics. По умолчанию откроется раздел Value stream. В Lean вообще и в DevOps в частности считается что задачи несут в конечном итоге некоторую пользу для конечного заказчика. И движение таких полезных задач, от стадии формулирования через все этапы работы до того момента когда результаты становятся доступны заказчику называется value stream.
Основные средние величины по этапам:
Если вы сложите длительность Issue, Plan, Code, Review и Staging, вы и получите примерно то самое заветное время для вывода на рынок (TTM).
Наверху страницы в также увидите некие агрегатные показатели по проекту за выбранный период времени.
Поздравляю!
Вы осуществили имплементацию непрерывной поставки(CD) при помощи GitLab начиная с задач с канбан-доской и завершая метриками.
Вышел GitLab 9.2: Несколько исполнителей задачи, конвейеры по расписанию, локализация, альфа аварийного восстановления
GitLab спроектирован таким образом, что каждый участник проекта может вносить свой вклад, независимо от размера команды и местонахождения ее участников.
Зачастую в процессе разработки продукта несколько человек работают над одной задачей: например, разработчики фронтэнда и бэкэнда, дизайнер интерфейса, тестировщик и менеджер продукта. С выходом GitLab 9.2 все они могут быть назначены исполнителями одной задачи, что упрощает процесс совместной разработки и позволяет наглядно отображать их общую область ответственности.
Также в версии 9.2 положено начало процесса локализации GitLab: аналитика цикла разработки (Cycle Analytics) теперь доступна на испанском и немецком языках. Локализация GitLab будет продолжена в последующих релизах, чтобы каждый мог вносить свой вклад независимо от родного языка.
Кроме того, разработчики получили больше контроля над временем выполнения конвейеров CI/CD. Теперь можно составлять расписание выполнения конвейеров, что позволяет автоматизировать периодические задачи, такие как ночные сборки, профилактика или подтверждение внешних зависимостей.
MVP этого месяца — Dosuken Shinya
Dosuken добавил дополнительные параметры поиска в интерфейс конвейеров. Это нововведение открывает множество возможностей: например, теперь можно с легкостью сформировать запрос на последний конвейер определенной ветки. Также Dosuken внес существенный вклад в прошлый релиз — он заложил основы выполнения конвейеров по расписанию. Спасибо, Dosuken!
Несколько исполнителей задачи (EES, EEP)
При работе с GitLab нередко появляются задачи, которые требуют совместных усилий сразу нескольких человек. Ранее в таких ситуациях было сложно понять, на кого назначена задача; это было особенно актуально для организаций, в которых исполнители не контактируют друг с другом ежедневно. С выходом GitLab 9.2 становится возможным назначить исполнителями одной задачи столько пользователей, сколько необходимо. Все они будут обладать равным уровнем ответственности и получать те же оповещения, что и в предыдущих версиях. Все исполнители отображаются в списке задач и досках задач, каждый из них может отслеживать свою связь с задачами на своей панели управления.
Локализация аналитики цикла разработки (Cycle Analytics) (CE, EES, EEP)
Hola Mundo, Hallo Welt! Мы рады сообщить, что, начиная с данного релиза, мы приступаем к работе над локализацией GitLab. Будем рады вашей поддержке в этом начинании!
В версию 9.2 добавлены инструментарий и инфраструктура для перевода GitLab на любой язык мира. Пока что в тестовых целях мы перевели только одну страницу (Cycle Analytics) на испанский и немецкий. В следующих версиях мы будем переводить новые страницы, а также добавлять другие языки. Если вы хотите помочь нам в этом — обратитесь к инструкции.
Для смены языка GitLab нажмите на свою иконку в правом верхнем углу экрана и зайдите в настройки (Settings).
Больше информации об аналитике цикла разработки в нашей документации
Запуск конвейеров по расписанию (CE, EES, EEP)
В большинстве проектов конвейеры CI/CD запускаются для каждого нового коммита — таким образом, все изменения в коде проходят сборку, тестирование и развертывание. Однако, существуют ситуации, в которых требуется запуск конвейера по определенному расписанию.
С выходом GitLab 9.2 становится возможным настроить запуск конвейеров тогда, когда нужно, и так часто, как нужно. Ежедневный и еженедельный запуск конвейеров, проверка внешних зависимостей или просто профилактические запуски — теперь все это можно легко настроить.
Данная функциональность полностью заменяет альфа-версию интерфейса для триггеров конвейеров по расписанию.
Больше информации о планировании запуска конвейеров в нашей документации
Установка GitLab на Kubernetes (CE, EES, EEP)
Мы хотим, чтобы GitLab был как можно лучшим инструментом для нативной облачной разработки. Для этого важно, чтобы вы могли легко начать работу с Kubernetes. Поэтому мы с радостью сообщаем, что с версией 9.2 выходят официальные Helm-чарты GitLab.
Helm — это инструмент управления пакетами, который позволяет проводить развертывание, апгрейд и настройку приложений в кластерах Kubernetes. GitLab и Kubernetes прекрасно взаимодействуют друг с другом: все идеи, представленные в нашем видео Idea to Production, такие как автоматизация масштабирования CI и развертывания в ваши кластеры, легко реализуются с минимумом дополнительной настройки.
Больше информации об установке GitLab при помощи Helm-чартов в нашей документации
Данные о воздействии мерж-реквестов на производительность (CE, EES, EEP)
В большинстве случаев нелегко отследить влияние определенного мержа на производительность системы. Зачастую, за данные о производительности отвечает отдельный инструмент, к которому у команды разработчиков даже нет доступа. Мы хотим, чтобы у разработчиков была возможность получать эти данные для каждого изменения, которое они вносят. Интеграция с Prometheus является большим шагом к достижению этой цели.
Начиная с GitLab 9.2 изменения в потреблении памяти после развертывания отображаются прямо в мерж-реквесте. Теперь разработчики могут отслеживать изменения в производительности, не отвлекаясь от привычного процесса работы. В последующих релизах мы планируем добавить другие метрики производительности.
Больше информации об отслеживании воздействия мерж-реквестов на потребление памяти в нашей документации
Улучшения альфа-версии аварийного восстановления (EEP)
Начиная с версии 9.0, в GitLab Geo входит альфа-версия аварийного восстановления. Мы стремимся улучшать ее с каждым новым релизом, и GitLab 9.2 не стал исключением. В новой версии мы сделали аварийное восстановление более удобным: смысл элементов управления стал более очевидным, а отчеты о процессе репликации — более подробными.
Также улучшился механизм репликации репозиториев: теперь повторная синхронизация для репозиториев, поврежденных из-за ошибок синхронизации, происходит автоматически. Кроме того, при обновлении основной базы данных происходит ее автоматическая синхронизация со вторичными базами.
Больше информации о GItLab Geo в нашей документации
Автоматическое обновление названий и описаний задач (CE, EES, EEP)
Поскольку страница задачи является основным местом совместной работы, ее содержимое постоянно меняется. Начиная с версии GitLab 9.2, название и описание задач обновляются автоматически, без обновления страницы. Так что теперь для того, чтобы постоянно видеть последнюю версию задачи, достаточно просто держать ее вкладку открытой. Даже название вкладки в браузере обновляется автоматически.
Кроме того, при редактировании описания задачи добавляется системная заметка, благодаря чему можно просмотреть полную историю изменений задачи просто пролистав ее комментарии. Эти изменения затронули и комментарии — они таким же образом автоматически обновляются при их редактировании.
Больше информации по задачам в нашей документации
Удаление фильтров в строке поиска (CE, EES, EEP)
Теперь вы сможете одним кликом удалять фильтры в строке поиска задач и мерж-реквестов.
Также мы изменили стиль ярлыков в строке поиска: теперь они соотносятся по цвету с остальными ярлыками по всему приложению.
Улучшенный поиск с помощью Elasticsearch (EES, EEP)
Мы добавляем больше возможностей расширенного поиска за счет интеграции с Elasticsearch. Если вы настроили Elasticsearch, вы можете искать точные фразы (в двойных кавычках) или неупорядоченный набор ключевых слов, по совпадению части слова или использовать другие возможности поискового синтаксиса. (Заметьте, что это относится к строке поиска в правом верхнем углу на любой странице GitLab, но не к поиску в списках задач и мерж-реквестов.)
Также благодаря Elasticsearch стал возможным глобальный поиск по всем вики в вашем инстансе.
Другие улучшения в GitLab 9.2
Создание мерж-реквеста из задачи (CE, EES, EEP)
В каждой итерации GitLab мы стараемся сделать путь от идеи к производству более быстрым и легким.
Эта новая маленькая фича позволит вам создать мерж-реквест прямо со страницы задачи, а необходимую для этого ветку GitLab создаст автоматически. Это особенно полезно, когда вам нужно сделать небольшой коммит прямо из интерфейса GitLab.
Комментарии для личных сниппетов (CE, EES, EEP)
В сниппетах (даже в личных) часто происходит совместная работа. В этом обновлении появятся треды комментариев для каждого личного сниппета — так же, как и для сниппетов проекта.
Дополнительно о сниппетах можно прочитать в нашей документации
Предпросмотр отрендеренного кода (CE, EES, EEP)
При просмотре файлов GitLab многие файлы, например, SVG & Markdown, отображаются в отрендеренной форме. На странице просмотра файла появился удобный маленький переключатель между режимами просмотра исходного кода и отрендеренного файла.
Поддержка Terraform для GitLab Runner на Google Compute Engine (CE, EES, EEP)
В GitLab 9.1 мы запустили поддержку установки GitLab на GCE через Terraform компании Hashicorp. В версии 9.2 мы также добавляем возможность разворачивать GitLab Runner, дополнив этим принцип «от идеи к производству».
Предпросмотр артефактов заданий в пользовательском интерфейсе (CE, EES, EEP)
Артефактом может быть любой файл; вы можете добраться до этого файла с помощью поиска по архиву прямо в пользовательском интерфейсе. GitLab 9.2 расширил возможности этого поиска: теперь у файлов PDF, картинок, видео и других форматов будет предпросмотр прямо в поиске артефактов заданий — их больше не нужно скачивать.
Больше информации о поиске артефактов заданий в нашей документации
Обработка неоднозначных маршрутов в динамических путях (CE, EES, EEP)
В GitLab есть несколько путей до конкретных фич. После введения вложенных групп эти фичи могли стать недоступными для тех проектов или групп, названия которых конфликтуют с этими путями. Например, для проекта под названием ‘badges’ бэйджи (badges) статусов сборки или покрытия стали недоступны.
Чтобы избежать таких недоразумений, мы убрали возможность создавать проекты или группы с названиями, которые могут конфликтовать с существующими маршрутами GitLab.
Учтите, что настройки git remote нужно будет обновить вручную, например, так:
После принятия мерж-реквеста ветка удаляется по умолчанию (CE, EES, EEP)
Начиная с GitLab 9.2 исходные ветки в мерж-реквестах по умолчанию удаляются. Если вы хотите сохранить ветку даже после мержа, вам нужно отключить опцию в виджете мерж-реквеста до его принятия.
Восстановление артефактов после кэширования файлов в заданиях CI (CE, EES, EEP)
С этого релиза артефакты можно восстанавливать после кэширования — чтобы убедиться, что они сохранятся и будут доступны даже в критической ситуации.
Улучшения пакета Omnibus (CE, EES, EEP)
GitLab Mattermost 3.9
GitLab 9.2 включает Mattermost 3.9, альтернативу Slack с открытым исходным кодом. В этом релизе мы добавили в нее новый каталог интеграций и поддержку польского языка, дополнили десктопные приложения проверкой орфографии и добавили еще много полезного.
Версия включает обновления безопасности. Рекомендуем обновиться.
Реестр GitLab
Реестр контейнеров GitLab (GitLab Container Registry) обновился с версии 2.4 до версии 2.6.1.
Назначение конкретных ревьюеров для мерж-реквестов (EES, EEP)
Интерфейс мерж-реквестов позволяет выбирать отдельных ревьюеров, которые смогут принять (подтвердить) этот реквест. На выбор предлагаются только участники проекта, а также группы, к которой принадлежит проект (parent group), и группы, которым предоставлен доступ к проекту (project share). Поэтому вы сможете легко найти нужных пользователей.
Комментирование в устаревших диффах (CE, EES, EEP)
В этом релизе появилась возможность ссылаться на устаревший дифф прямо из треда обсуждения мерж-реквеста. Это позволит быстро обращаться к содержимому старых коммитов в процессе разработки, совместной работы и ревью. Вы даже сможете оставлять комментарии в тех устаревших диффах.
Развертывания отображаются на доске производительности (CE, EES, EEP)
Если производительность продукта поменялась, то первый вопрос — менялось ли рабочее окружение? GitLab 9.2 теперь быстро отвечает на этот вопрос, отображая все развертывания в окружении прямо на доске мониторинга. Это позволяет сразу видеть зависимость между изменениями в производительности и новой версией приложения (и все это не покидая GitLab).
Ручные действия учитывают защищенные ветки (CE, EES, EEP)
Для ручных действий теперь требуются те же права доступа, что и на запись в репозиторий, что позволит контролировать, кто может их совершать. Например, теперь можно оставить право на ручной запуск задачи по развертыванию кода из стабильной ветки на production только для пользователей, имеющих право на коммит в эту ветку.
Это очень важная часть в списке улучшений системы безопасности, которые мы добавляем в GitLab для защиты развертывания в ваших проектах. Подробности можно прочитать в этой задаче.
Вкладка неудавшихся заданий, резюмирующая все отказы (CE, EES, EEP)
Когда вы совершаете коммит новой части кода в проект с continuous integration (CI), обычно вы ожидаете увидеть отметку, которая обозначает, что конвейер выполнен успешно, и все сработало так, как было задумано. В случае, если что-то пошло не так, нужно как можно быстрее узнать подробности. Но многочисленные переходы по каждому из этапов и заданий не очень вдохновляют, особенно если конвейер сложный.
В GitLab 9.2 на странице информации о конвейере (в разделе Pipelines выбрать конкретный конвейер) появилась вкладка Failed Jobs. На ней можно посмотреть логи всех проваленных заданий и оценить общую картину выполнения конвейера.
