Что такое issue в gitlab
Как эффективно работать с тикетами (issues) на GitHub
Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.
Содержание:
Что такое тикет?
Для многих команд «тикет» — это общий термин, который может означать:
Публичный или приватный?
Для проектов можно создавать публичные и приватные тикеты. Публичные, как правило, предназначены для пользователей, клиентов, агентов и т. д. Приватные — для разработчиков, подрядчиков, партнёров и т. д.
Для публичных тикетов
Для приватных тикетов
Оценка
Все тикеты надо оценивать таким образом, чтобы иметь возможность сравнить их друг с другом и понять, над чем именно нужно работать. Есть разные способы оценки, и на практике хорошо работают следующие.
Оценка по приоритетности
Оценка по степени влияния
Оценка по степени ущерба
Оценка по размеру
Оценка по критерию MoSCoW
Оценка по частоте
Совокупная оценка
Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.
Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.
Обсуждение оценок
Здесь приведены примеры обсуждения оценок тикетов.
— Обычно кроме опасности независимо оценивается и частота. Если баг вряд ли проявится при обычном использовании, то даже при высокой опасности приоритетность может быть понижена. Обычно так управляют рисками.
— Разработчик или тестировщик может хорошо оценивать опасность бага, но он не знает, столкнутся с этой проблемой все пользователи или только некоторые из них. Частота — это другое измерение. Приоритетность можно вычислить, умножив опасность на частоту.
— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.
— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.
— У некоторых пользователей программа иногда вылетает, они теряет всю сделанную работу и очень сильно злятся. Они присваивают тикету высочайшую опасность. Но если с проблемой сталкивается только один человек, и это происходит периодически, причём пользователь уже приспособился чаще сохраняться, тогда продуктологу следует задать тикету более низкую приоритетность.
— Опасность характеризует восприятие проблемы человеком: если он сталкивается с ней в определённом случае, то он оценит опасность как максимальную. Приоритетность описывает, как воспринимает баг команда управления проектом: более высокое значение получают баги, о которых сообщают наиболее ценные жалобщики — приносящие много денег клиенты, столкнувшийся с затруднениями директор и т. д. Не используйте опасность багов для оценки приоритетности, потому что они взаимосвязаны опосредовано.
— Опыт использования приоритетности и опасности подсказывает, что в теории различие между ними может быть, но в реальности большинство его не видят. Эти термины так часто путают, что они стали неразделимы.
— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).
— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Запустить разбор можно:
Manage issues
GitLab Issues are the fundamental medium for collaborating on ideas and planning work in GitLab.
Create an issue
When you create an issue, you are prompted to enter the fields of the issue. If you know the values you want to assign to an issue, you can use quick actions to enter them.
From a project
The newly created issue opens.
From a group
Issues belong to projects, but when you’re in a group, you can access and create issues that belong to the projects in the group.
The newly created issue opens.
The project you selected most recently becomes the default for your next visit. This can save you a lot of time and clicks, if you mostly create issues for the same project.
From another issue
New issue becoming linked to the issue of origin introduced in GitLab 14.3.
You can create a new issue from an existing one. The two issues can then be marked as related.
The newly created issue opens.
From an issue board
You can create a new issue from an issue board.
By sending an email
Generated email address format changed in GitLab 11.7. The older format is still supported, so existing aliases and contacts still work.
You can send an email to create an issue in a project on the project’s Issues List page.
A new issue is created, with your user as the author. You can save this address as a contact in your email client to use it again.
Using a URL with prefilled values
Adapt these examples to form your new issue URL with prefilled fields. To create an issue in the GitLab project:
With a prefilled title and description:
With a prefilled title and description template:
With a prefilled title, description, and marked as confidential:
Using Service Desk
To offer email support, enable Service Desk for your project.
Now, when your customer sends a new email, a new issue can be created in the appropriate project and followed up from there.
Fields in the new issue form
Adding the new issue to an epic introduced in GitLab 13.1.
Edit an issue
You can edit an issue’s title and description.
Bulk edit issues from a project
You can edit multiple issues at a time when you’re in a project.
Bulk edit issues from a group
You can edit multiple issues across multiple projects when you’re in a group.
Move an issue
When you move an issue, it’s closed and copied to the target project. The original issue is not deleted. A system note, which indicates where it came from and went to, is added to both issues.
Bulk move issues
You can move all open issues from one project to another.
Close an issue
When you decide that an issue is resolved or no longer needed, you can close it. The issue is marked as closed but is not deleted.
In an issue board, drag an issue card from its list into the Closed list.
Reopen a closed issue
To reopen a closed issue, at the top of the issue, select Reopen issue. A reopened issue is no different from any other open issue.
Closing issues automatically
You can close issues automatically by using certain words in the commit message or MR description.
Alternatively, when you create a merge request from an issue, it inherits the issue’s milestone and labels.
For performance reasons, automatic issue closing is disabled for the very first push from an existing repository.
Default closing pattern
To automatically close an issue, use the following keywords followed by the issue reference.
The default issue closing pattern regex:
Disable automatic issue closing
You can disable the automatic issue closing feature on a per-project basis in the project’s settings.
Referenced issues are still displayed, but are not closed automatically.
The automatic issue closing is disabled by default in a project if the project has the issue tracker disabled. If you want to enable automatic issue closing, make sure to enable GitLab Issues.
Changing this setting applies only to new merge requests or commits. Already closed issues remain as they are. If issue tracking is enabled, disabling automatic issue closing only applies to merge requests attempting to automatically close issues in the same project. Merge requests in other projects can still close another project’s issues.
Customize the issue closing pattern
To change the default issue closing pattern, edit the gitlab.rb or gitlab.yml file of your installation.
Change the issue type
Delete an issue
Deleting from the vertical ellipsis menu introduced in GitLab 14.6.
Promote an issue to an epic
You can promote an issue to an epic in the immediate parent group.
Alternatively, you can use the /promote quick action.
Add an issue to an iteration
Alternatively, you can use the /iteration quick action.
Copy issue reference
You can now paste the reference into another description or comment.
Read more about issue references in GitLab-Flavored Markdown.
Copy issue email address
You can create a comment in an issue by sending an email. Sending an email to this address creates a comment that contains the email body.
To learn more about creating comments by sending an email and the necessary configuration, see Reply to a comment by sending email.
Real-time sidebar
Assignees in the sidebar are updated in real time.
Assignee
An issue can be assigned to one or more users.
The assignees can be changed as often as needed. The idea is that the assignees are people responsible for an issue. When an issue is assigned to someone, it appears in their assigned issues list.
If a user is not a member of a project, an issue can only be assigned to them if they create it themselves or another project member assigns them.
Similar issues
To prevent duplication of issues on the same topic, GitLab searches for similar issues when you create a new issue.
As you type in the title text box of the New issue page, GitLab searches titles and descriptions across all issues in the current project. Only issues you have access to are returned. Up to five similar issues, sorted by most recently updated, are displayed below the title text box.
Health status
To help you track issue statuses, you can assign a status to each issue. This status marks issues as progressing as planned or needing attention to keep on schedule.
You can then see the issue’s status in the issues list and the epic tree.
After an issue is closed, its health status can’t be edited and the Edit button becomes disabled until the issue is reopened.
Publish an issue
If a status page application is associated with the project, you can use the /publish quick action to publish the issue.
For more information, see GitLab Status Page.
Issue-related quick actions
You can also use quick actions to manage issues.
GitLab 8.11: канбан-доска и разрешение конфликтов одним кликом
Эта статья — перевод релизной статьи компании GitLab. Релизы выходят каждый месяц 22 числа.
Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8
В новом GitLab 8.11 столько всего интересного, что мы с трудом сдерживаем себя в рамках конструктивного повествования!
Итак, в новой версии появились:
MVP этого месяца — Clement Ho. Спасибо ему за мерж-реквесты и отзывчивость в работе над задачами.
Доска тикетов (Issue Board)
Тикеты (issues) в GitLab — очень гибкий инструмент. Они могут содержать ссылки друг на друга, можно обозначить их приоритеты, можно отсортировать по популярности. Доска тикетов добавляет новый способ работы с ними.
Теперь можно настраивать рабочие процессы (workflows) и быстро получать информацию о состоянии тикетов. Всё это доступно на простой и приятной глазу доске, похожей на те, что используются в Канбане или Скраме.
Доска создается для каждого проекта автоматически. По умолчанию все открытые тикеты формируют список-бэклог (Backlog), а все закрытые появляются в списке завершённых (Done list).
Добавляя новые списки, вы создаёте новые рабочие процессы. Принадлежность тикета к списку определяется меткой. При добавлении тикета в список к ней добавляется соответствующая метка, при удалении из списка — метка удаляется.
Если хотите посмотреть на эту фичу в действии, загляните на доску GitLab CE версии 8.12.
Разрешение конфликтов при мерже
Мержи в крупных и активно разрабатываемых проектах обычно вызывают много проблем. Мы хотим, чтобы у вас был встроенный инструмент для разрешения конфликтов. Поэтому теперь можно это делать прямо в интерфейсе GitLab.
Когда мерж блокируется конфликтом, можно просто нажать кнопку «Resolve these conflicts» и перейти в интерфейс разрешения. Там можно выбрать нужные строки и закоммитить полученный результат.
Разумеется, так получится разрешить далеко не все конфликты. Но мы надеемся, что в большинстве случаев этот инструмент поможет вам ускорить прохождение мерж-реквестов.
Разрешения на работу с ветками для конкретных пользователей (только EE)
Теперь в Enterprise Edition можно настраивать разрешения на пуш или мерж в ветку не только для подгрупп пользователей (как developers или owners ), но и для конкретных пользователей.
Новые настройки можно совмещать с другой функциональностью, в том числе с разрешениями для подгрупп. Например, можно разрешить пушить непосредственно в ветку только тимлидам Пете и Маше, но подтверждать мерж-реквесты в эту ветку — всем членам группы уровня developer и выше.
Для каждого действия (пуш и мерж) можно настроить любое количество авторизованных пользователей.
«Закрытие» комментариев в мерж-реквестах.
В мерж-реквестах бывают длинные ветки комментариев, в которых можно запутаться. Но каждый из них важен.
Мы добавили возможность отметить комментарий или целую ветку как обработанную и закрыть её.
В мерж-реквестах теперь также есть счётчик незакрытых обсуждений и удобная кнопка перехода к к следующему открытому обсуждению.
Схемы конвейеров.
Конвейеры в GitLab могут иметь достаточно сложную структуру с множеством последовательных и параллельных сборок. Теперь можно посмотреть на схему конкретного конвейера, отображающую его строение и состояние. Такая схема наглядно показывает происходящие в нём процессы.
Просто кликните на конвейере на странице мерж-реквеста или в списке конвейеров. Вы увидите схему этого конвейера с отображением выполненных, проваленных, активных и ожидающих сборок.
Шаблоны тикетов и мерж-реквестов.
Возможность стандартизировать тикеты и мерж-реквесты с помощью шаблонов уже была в GitLab Enterprise Edition. Начиная с GitLab 8.11 шаблонов может быть много — например, один для ошибок, а другой для предложений. А сама возможность есть во всех версиях: GitLab.com, GitLab CE/EE.
Цель этой фичи — улучшить внешний вид и полноту предложений, сообщений об ошибках и мерж-реквестов.
Слеш-команды
Теперь в GitLab есть слеш-команды ( /command ) — так же, как в IRC, HipChat, Mattermost или Slack. Они позволяют менять метки, назначать исполнителей, подписываться и отписываться от тикетов и делать многое другое — быстро и не отрывая рук от клавиатуры. Команды работают в описании тикета или мерж-реквеста, а также в комментариях.
Как ими пользоваться:
Можно использовать слеш-команды даже при создании нового тикета или реквеста:
Если последовательно указать несколько команд, то все они будут выполнены.
Несколько идей, как можно использовать слеш-команды:
Мы сами с нетерпением ждём ваших рассказов о том, какие ещё способы использования вы изобретёте.
Интеграция с Koding
Koding позволяет запускать среду разработки в облаке, использовать единые настройки этой среды для всей команды и даже использовать локальный редактор. Благодаря этому не нужно тратить время на установку и настройку стека для каждого нового компьютера и при любом изменении.
Начиная с версии 8.11 GitLab поддерживает интеграцию с Koding. Теперь одним нажатием кнопки можно выкачать проект целиком или отдельный мерж-реквест и открыть его в полноценной облачной IDE. (обратите внимание, что на GitLab.com интеграция с Koding пока не добавлена).
Включите поддержку Koding в Admin > Application settings
Настройте Koding для работы с вашим проектом:
И все! Теперь вы можете быстро выкачать любой мерж-реквест, ветку и коммит проекта в полноценную IDE.
Мы подготовили небольшое видео, показывающее процесс работы связки Koding + GitLab:
Для того, чтобы узнать больше о Koding в GitLab, обратитесь к нашей документации.
Конвейеры в мерж-реквестах
Теперь конвейеры отображаются в мерж-реквестах:
Нажмите на конвейер, чтобы увидеть его схему и билды, относящиеся к нему.
Отображение статуса развертывания для мерж-реквестов
Теперь вы можете указывать URL для своих сред развертывания (environments):
Благодаря этому GitLab показывает статус развертывания для мерж-реквестов в случаях, когда развертывание происходит автоматически при мерже:
После успешного мержа GitLab покажет вам ссылку на среду развертывания, что позволяет увидеть результат мерж-реквеста в один клик.
Веб-хуки для конвейеров (pipelines)
Для упрощения интеграции с конвейерами GitLab мы добавили веб-хуки для них. Они срабатывают при создании, запуске или завершении работы конвейера.
Для того, чтобы добавить веб-хук, выберите Webhooks в меню Settings вашего проекта.
Подсветка и скрытие кода
Теперь редактор GitLab поддерживает подсветку и позволяет скрывать блоки кода.
Ссылки на мерж-реквесты при пуше
Теперь при пуше на GitLab появляются ссылки на создание мерж-реквеста, а также на все мерж-реквесты, имеющие отношение к текущему.
Значок покрытия тестами (test coverage)
Появилась возможность создавать значки, показывающие покрытие тестами вашего проекта:
Временные ограничения на доступ к проекту
При выдаче доступа к проекту одиночному пользователю, либо группе, теперь можно установить определенную дату, после которой доступ к проекту будет для них закрыт.
Это упрощает работу с правами доступа для временных членов команды.
Перемещение проектов между шардами (только EE)
В GitLab 8.10 были добавлены множественные точки монтирования (mount points).
В GitLab 8.11 появилась возможность перемещать проекты между шардами (shards) при помощи команды rake. Эта функциональность не предполагается для частого использования, однако она может оказаться полезной в случаях, когда вы хотите протестировать новый шард или переместить часто используемый проект на хранилище с быстрым доступом.
Улучшения производительности
В данном релизе был введен ряд изменений направленных на повышение производительности — мерж-реквесты и их диффы стали еще быстрее! Ниже приведены графики, показывающие разницу в производительности после развертывания GitLab 8.11 RC2 на GitLab.com (падение в производительности попадает на развертывание).
Время загрузки диффов для мерж-реквестов:
Количество выполненных SQL-запросов при отображении диффов:
Время, потраченное на выполнение SQL-запросов при отображении диффов:
Также значительно повысилась производительность конвейеров:
Ниже приведен детальный список проведенных улучшений и соответствующих мерж-реквестов:
Улучшения
Новые фичи
Инструментирование
GitLab Mattermost 3.3
В Mattermost 3.3 добавлены локализации на китайский, корейский и голландский языки, бот на Go,
возможность помечать (flag) посты, упоминания вида @here и многое другое.
Кроме того, в этоу версию Mattermost вошли несколько security updates, поэтому мы настоятельно рекомендуем обновиться на нее.
Поддержка Redis Sentinel
В GitLab теперь еть экспериментальная поддержка Redis Sentinel.
Прочие изменения
Этот релиз включает в себя и многие другие улучшения, включая различные security fixes. Полный список изменений доступен в Changelog.
Upgrade-барометр
Обновление до GitLab 8.11 потребует даунтайма из-за миграций баз данных
Даунтайм для сайта GitLab.com (самый крупный из известных нам инстансов GitLab) составил 15-30 минут. В зависимости от количества данных на вашем инстансе ваш даунтайм может быть меньше.
Одна из миграций удаляет несколько столбцов в нескольких таблицах (и инстанс GitLab нужно свернуть, чтобы эти данные не пропали в процессе доступа к ним).
Две другие миграции создают новые таблицы и наполняют их информацией на основе уже существующих в системе данных: в этом случае даунтайм нужен, чтобы добавляемые данные не поменялись в процессе работы миграции (и оставались неизменными, пока развертывание 8.11 не завершено полностью).
Наконец, еще одна миграция добавляет два внешних ключа (foreign keys), и здесь даунтайм нужен для гарантии отсутствия одновременного доступа к изменяемым данным.
Устаревание (deprecation) Ruby 2.1
С этим релизом мы обновили Ruby до версии 2.3.
Для ручных установок мы настоятельно рекомендуем вам обновить Ruby до 2.3. Установки GitLab, сделанные через Omnibus, автоматически будут использовать Ruby 2.3.
Поддержка Ruby 2.1 и 2.2 будет полностью прекращена в GitLab версии 8.13.
Для тех, кто обновился раньше остальных
Форсированная двухфакторная аутентификация при использоваии GitLab API и Git поверх HTTP
Если у вас включена двухфакторная аутентификация и вы пытаетесь получить API-токен через метод /sessions или Resource Owner Password Credentials flow provided в OAuth2, то вы не сможете залогиниться. Для успешного логина в этих случаях вам нужно будет использовать Personal Access Token.
Реиндексирование Elasticsearch (только для EE)
Мы изменили структуру индексов 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/
Обновление
Enterprise Edition
GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп. Подробную информацию можно посмотреть в описании GitLab EE.
GitLab EE доступен только по подписке, подробности и цены можно посмотреть вот тут.
Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах.