Продолжение истории о инструментах сопровождения разработки.
Что-то давно я ничего не писал по этому поводу, хотя с момента второй части произошли существенные изменения 🙂
Если совсем коротко — то мы начали использовать redmine. Но это наверное не так интересно. Поэтому далее опишу как мы построили наш процесс. Возможно кому-то это будет интересным, а может еще и полезным.
Напомню вкратце, что redmine — это таск-баг-трекер. Он написан на Ruby, у него вполне приличный интерфейс и функционал, есть поддержка тем оформления и расширения функционала с помощью плагинов.
Для нашего процесса мы подготовили несколько ролей, несколько разных трекеров, работа по которым различается, подключили репозитории с исходниками и описали алгоритмы взаимодействия. Но давайте обо всем по порядку.
Начну с трекеров. Для наших задач мы завели 3 трекера: «Ошибка», «Улучшение», «Новый функционал». На самом деле алгоритм работы по трекеру «улучшение» и «новый функционал» один и тот же, но так проще разделять задачи. Еще мы сразу завели трекер «Поддержка» для задач сопровождения, но его мы пока не используем.
Так же мы настроили необходимые статусы задач. У нас их целых 10. Может показаться, что их слишком много, но в симбиозе с настроенными ролями и правилами изменений статусов получилось все очень не плохо.
Общая идея здесь вполне понятная: изначально задача по любому трекеру регистрируется в статусе «новая», затем она назначается исполнителю ответственным разработчиком, берется в работу, исправляется, принимается, отдается в тестирование и либо успешно закрывается, либо возвращается как повторная.
Далее мы завели роли и настроили права для изменения статусов задач.
В нашем случае определены следующие роли:
В нашей идеологии проект в редмайн — это конкретный программный компонент (сервис, веб-приложение, вин-приложение, модуль, библиотека и т.д.). Проект может состоять из подпроектов. У каждого проекта есть своя команда разработки. В рамках этой команды обязательно есть ответственный разработчик — это тот, кто отвечает за проект в целом, за выпуски версий, декомпозицию задач от менеджеров, архитектуру проекта и т. д. Так же есть ответственный тестировщик, который отвечает за тестирование данного проекта в целом. Роль репортёра у нас назначается всем, кто так или иначе сталкивается с данным проектом, чтобы иметь возможность зарегистрировать ошибку и получать доступ к описаниям и материалам по проекту, которые выкладываются в редмайн.
Каждая роль имеет свои права и правила изменения статуса задач. Например, разработчик не может просто так взять и завершить задачу, он обязательно должен отправить задачу на код-ревью в виде мердж-реквеста, отметив факт выполнения работы. А вот ответственный разработчик, в случае принятия мердж-реквеста, выставит задаче статус «Одобрена». Точно так же, только тестировщик может принять решение о том, что задача «завершена» только после тестирования, а никто из разработчиков не может заранее завершить задачу.
Вот несколько примеров наших правил статус-переходов.
Так выглядят статус-переходы по трекеру «Ошибка»
А вот статус-переходы по трекеру «Новый функцонал»
Помимо статус-переходов, у разных ролей есть право на изменение определенных полей в задачах. Например, только ответственный разработчик может выставить номер сборки, в которую войдет тот или иной функционал или исправление.
Работу с исходным кодом, а именно задачи код-ревью и мердж-реквестов, мы оставили на стороне gitlab’а. Он нам очень нравится и вполне устраивает. В гитлабе есть интеграция с редмайном, она правда сводится к тому, что ссылка на issues ведет на соответствующую страницу проекта в редмайн :).
В редймане есть возможность ссылаться на задачи прямо из коммит-сообщений. Для этого необходимо настроить хранилища для каждого проекта и указать паттерны, по которым редмайн будет понимать что хотел сказать разработчик 🙂
Редмайн сам по себе не умеет следить за изменениями в хранилище, для этого надо запускать через rake соответствующий таск: /usr/local/bin/rake redmine:fetch_changesets RAILS_ENV=production. Более того, редмайну нужен именно working tree, а не bare репозиторий. Поэтому для получения изменений надо выполнять git pull и затем уже redmine:fetch_changesets. В инете везде предлагается делать это через cron-скрипт, который периодически получает изменения в репозиториях и запускает rake. Но как-то это не интересно. Если репозиториев много — дергать их все часто не хочется. Поэтому мы написали парочку небольших скриптиков: один по гит-хуку post-receive отправляет по HTTP POST-запрос с git-сервера на сервер с редмайном, а второй — обрабатывает этот запрос, обновляет соответствующий репозиторий, и дергает редмайн для обновления чендж-сетов. Для тех, кому интересно, скрипты можно посмотреть на гитхабе.
Ну вот, теперь можно описать весь регламент работы с трекером.
Жизненный цикл задачи по трекеру «Ошибка»
- Ошибка регистрируется тестировщиком или иным зарегистрированным пользователем в Redmine, исполнителем ошибки назначается ответственный разработчик (см. информацию по проекту, где указаны роли и пользователи). Статус ошибки — «Новая».
-
Ответственный разработчик анализирует ошибку.
- Если он соглашается на наличие ошибки, то устанавливает статус ошибки «Назначена», указывает разработчика, который будет исправлять ошибку.
- Если ошибки нет, то он меняет статус ошибки на «Отклонена», пишет комментарий по этому поводу, меняет значение поля «Назначена» на автора ошибки. Go to п.4.
- Если это не ошибка, а улучшение, то ответственный разработчик переводит её в трекер «Улучшение».
- Если ошибка относится к другому продукту, то ответственный разработчик должен изменить проект у ошибки и назначить её на соответствующего ответственного разработчика.
-
Разработчик принимает ошибку, по факту приступления к работе над ошибкой, устанавливает у неё статус «В работе».
- Если у разработчика возникают вопросы по ошибке, он пишет их в комментарии, меняя при этом поле «Назначена» на того, кому адресуется вопрос (например, автору ошибки). Автор ошибки отвечает на вопросы и обратно переводит ошибку на разработчика. Однако не стоит всегда прибегать к этому шагу, если вопрос простой — значительно проще, быстрее и эффективнее напрямую спросить у автора ошибки и тут же получить ответ.
- Разработчик может отклонить ошибку по какой-либо причине (изменился функционал, ошибка не воспроизводится, ошибка относится к другому продукту и т.д.). Переводит ошибку на ответственного разработчика, пишет комментарий по этому поводу. Ответственный разработчик принимает решение по ошибке — вернуть её обратно разработчику (Go to п.5) или отклонить на автора ошибки.
- Автор ошибки может оспорить решение ответственного разработчика (п.2.2), и после своей аргументации переводит ошибку в статус «Назначена», меняет значение поля «Назначена» обратно на ответственного разработчика. Go to п.2.
-
Разработчик исправляет ошибку, меняет статус ошибки на «Реализована/Исправлена». При этом, это можно сделать автоматически при коммите в git, указав в сообщении один из паттернов: fixes #taskid,closes #taskid,finishes #taskid,task done #taskid,bugfix closed #taskid,bugfix done #taskid.
- Если ответственный разработчик отклоняет исправление, то пишет комментарий по этому поводу и возвращает задачу разработчику (со статусом «Назначена» или «В работе»).
- Если ответственный разработчик принимает исправление, то меняет статус ошибки на «Одобрена», выставляет значение поля «Версия» (куда войдет исправление), меняет значение поля «Назначена» на «ответственного тестировщика».
- Осуществляется сборка. Ответственный тестировщик перекидывает ошибки, которые вошли в сборку, на тестировщика: переводит ошибку в статус «На тестировании», меняет значение поля «Назначена» на «тестировщика».
-
Тестировщик принимает ошибку в работу.
- Если тестировщик убеждается, что ошибки нет, всё корректно исправлено, то он изменяет статус ошибки на «Завершена».
- Если тестировщик обнаружил недочеты/неточности (не до конца или не так исправлено), то он меняет статус ошибки на «Повторная», меняет значение поля «Найдено в версии» на»текущую версию», пишет комментарий по этому поводу, меняет значение поля «Назначена» на «ответственного разработчика». Go to п.2.
Если ошибка является дубликатом, блокирует тестирование другой ошибки или необходимо связать несколько ошибок между собой и т.д., то необходимо использовать «Связанные задачи» и «Подзадачи».
Жизненный цикл задачи по трекерам «Улучшение» / «Новый функционал»
- Задача оформляется зарегистрированным пользователем в Redmine с ролями менеджера или ответственного разработчика в рамках проекта, исполнителем задачи назначается ответственный разработчик (см. информацию по проекту, где указаны роли и пользователи). Статус задачи — «Новая».
-
Ответственный разработчик анализирует задачу.
- Если он соглашается с ней, то меняет статус задачи на «Назначена», переводит задачу на программиста.
- Если он отклоняет задачу, то меняет статус задачи на «Отклонена», переводит задачу на её автора. Автор задачи может вернуть её обратно на ответственного разработчика с аргументированным комментарием.
- Разработчик принимает задачу, устанавливает у неё статус «В работе». Если у разработчика возникают вопросы по задаче, он пишет их в комментарии, меняя при этом поле «Назначена» на того, кому адресуется вопрос. Адресат отвечает на вопросы и обратно переводит задачу на разработчика.
- Разработчик реализует задачу, меняет её статус на «Реализована/Исправлена». Это можно сделать автоматически при коммите в git, указав в сообщении один из паттернов: fixes #taskid,closes #taskid,finishes #taskid,task done #taskid.
-
Ответственный разработчик проводит анализ реализации задачи.
- Если ответственный разработчик отклоняет реализацию задачи, то пишет комментарий по этому поводу и возвращает задачу разработчику (на статус «Назначена» или «В работе»).
- Если ответственный разработчик принимает реализацию задачи, то меняет её статус на «Одобрена».
- Ответственный разработчик закрывает задачу, меняет её статус на «Завершена», проставляет значение поля «Версия» на ту, куда войдет эта задача.
Для разработчиков: Подробный алгоритм разработки нового функционала/исправления ошибки
Мы живем по такой методологии уже несколько месяцев и нас все устраивает. Следующий этап — это интеграция с continuous integration сервером для автоматического запуска юнит-тестов, всяких проверок и т.д. Но об этом в другой раз, когда все доделаем и будет время об этом написать 🙂 А пока что, разрешите откланяться.
Ссылки на упоминавшиеся ресурсы и другие заметки из этой серии.