Mantis: Охотник на BUG-и. Часть 1

В разработке программного обеспечения важнейшую часть занимает вопрос координации усилий всех участников, вопрос обмена ими информацией, учета и планирования работ. Не секрет, что хороший продукт создается, прежде всего, не индивидуальным мастерством отдельных программистов, а четкой последовательностью шагов, начиная от сбора требований заказчиков и анализа, далее к построению архитектуры приложения, собственно, программированию и завершающим этапом идет оценка качества. Для того чтобы связать эти этапы в живую цепь, нужны специальные инструменты. И сегодня мы поговорим об одном из подобных средств – mantis.

Тема сегодняшней статьи - mantis (домашний сайт проекта сайт ) - относится к классу продуктов “issue tracker”. То есть является специальной базой данных, в которой регистрируются задачи, возникающие по ходу выполнения проекта. Не секрет, что в ходе разработки программного продукта проходит множество обсуждений, телефонных звонков, обмена e-mail-ами, но все это сводится к формированию четкого задания “выполнить задачу такую-то”. Эти задачи регистрируются в mantis или любой другой issue tracker системе. Затем задача возлагается на какого-то исполнителя (конкретного сотрудника или отдел), который и выполняет ее. На следующем этапе нужно проверить, что в ходе работы не было допущено ошибок, и эту часть работы выполняет отдел управления качеством QA (QM). Найденные ошибки регистрируются внутри все той же mantis и возвращаются на доработку отделу программистов. Возможна и такая ситуация, когда найденная отделом QA ошибка будет отвергнута, так как содержит неточное описание условий, которые нужно воспроизвести для того, чтобы найти ошибку. Возможно, что ошибка будет признана совсем не ошибкой, а “фичей” (feature), то есть немного непривычное, но все-таки правильное поведение приложения, и не подлежит исправлению. Задачи могут сменять своих владельцев, откладываться на определенный срок, открываться повторно. Задачи могут быть связаны между собой или организовываться в иерархии зависимостей.

В общем, ситуаций, возникающих по ходу решения задач, может быть много, но все сводится к одному. Нам нужна специализированная база данных, в которой будут регистрироваться все задачи, которые нужно выполнять. Каждое из этих заданий может иметь сложный жизненный цикл, в котором чередуются операции открытия, назначения, отзыва, приостановки, смены приоритета задания, постановки на проверку и как финальный аккорд — закрытие выполненной работы. Более того, эта база заданий не может существовать независимо от остальных частей и поддерживающих инструментов в разработке ПО. Если команда хранит проект, его исходные коды в системе управления версиями документов (CVS, SVN, Perforce), то каждый измененный файл, каждая ревизия (версия) файла может иметь ссылку на свой issue в базе mantis. Так мы сможем в любой момент времени ответить на вопрос: “Для чего был изменен вон тот файл, какую проблему мы решили в его новой ревизии”. Кроме связи с cvs|svn, хорошая система управления заданиями должна иметь средства интеграции с программами, специализированными для подготовки документации. К примеру, для того, чтобы выполнять задание, обязательным является наличие спецификации, подробно описывающей, что и как делать. Спецификация может содержать текст со сложным форматированием, картинки, схемы, таблицы и, конечно же, содержимое спецификации также может меняться со временем. Для ведения подобных документов существует множество коммерческих и свободных проектов, наиболее известным из которых является mediawiki (и его братья-близнецы TikiWiki, WackoWiki, confluence).

Возвращаясь назад, к описанию минимального джентльменского набора средств любой уважающей себя системы issue tracker, нужно подчеркнуть обязательность наличия средств интеграции с внешней системой подготовки и хранения документов и их версий. Критически важным является наличие средств оповещения всех заинтересованных участников об определенных событиях, происходящих внутри базы с задачами. К примеру, когда программист завершает исправление бага, то он меняет его статус. И тут же issue tracker должна послать письмо тестеру, который будет проверять выполненную работу. Для каждого из заданий можно назначать планируемое и реальное время выполнения работы и таким образом оценивать продуктивность работы команды. Как видите, issue tracker позволяет внести порядок в традиционный хаос выполнения работ, она дает возможность программисту четко видеть, какие работы ему нужно выполнить, какие у них приоритеты, видеть для каждой задач ее историю. “Большие” начальники могут, не вникая в подробности, окинуть список задач и узнать то, “на каком они свете”, успевают или нет реализовать все функции к дате выпуска новой версии продукта. Можно быстро обнаруживать ситуации, когда один “провисающий баг” у программиста Васи не дает возможности перейти к выполнению своего «куска» работы другой части команды. Можно изменять приоритеты заданий и менять лиц, ответственных за их выполнение, и все эти изменения будут четко зафиксированы. Как вывод: контроль должен быть, и нам нужны хорошие инструменты, помогающие этот контроль осуществлять.

Mantis (англ. богомол) – это одна из самых известных и популярных систем контроля выполнения заданий. Ее используют не только в сфере разработки программных продуктов, но и в других областях, где можно четко сформировать задания, этапы работы и их жизненный цикл. Одним из ярких примеров являются службы customer support (например, служба поддержки хостинга сайтов). В таких системах каждая поступившая заявка регистрируется и в зависимости от своего типа (техническая, финансовая, жалоба на качество обслуживания) назначается на ответственное лицо, а вам выдается номер билета (ticket). Как только проблема будет решена, вам придет извещение на электронную почту. То есть в корне пресекается такая ситуация, когда “ваше письмо мы не получали и делать ничего не будем”. В ходе возникающей переписки с support-ом нет необходимости приводить длинные “простыни” цитат из предыдущих писем, чтобы ввести кого-то в курс дела - достаточно сослаться на номер билета. А лучше всего добавлять примечания в специализированную форму на сайте, чтобы ваши письма и ответы на них были сгруппированы в одном месте, и можно было проследить всю историю общения. Все чаще issue tracker системы применяются не только для общения внутри технических отделов, но и служат “точкой доступа” для клиентов, чтобы они могли в любой момент времени зайти на сайт компании-партнера и увидеть ход выполнения работ. Более того, недавно один мой знакомый, работающий в сфере торговли, то есть совсем не связанной ни с программированием, ни с разработкой веб-сайтов, с гордостью рассказывал, что они у себя на сайте внедрили issue tracker, настроили права доступа. И теперь приучают своих клиентов не звонить с вопросами “а как там наш заказ”, а смотреть ход его выполнения с помощью браузера. Конечно, подобный шаг возможен не всегда, но если компания занимается обработкой большого количества небольших заказов, очень даже вероятно, что использование issue tracker уменьшит объем рутинной работы офисному персоналу. Весной прошлого года я написал серию из четырех статей, рассказывающих о JIRA – эталонной, по моему мнению, системе issue tracker. После публикации мне пришло много писем с просьбами рассказать о каких-то нюансах использования JIRA, настройки ее так, чтобы поддерживать новый, специфический жизненный цикл задач (создание custom workflow). Тем не менее, были и “злобные” письма, говорящие, что неправильно писать о продуктах стоимостью в несколько тысяч долларов и требующих для своей работы специализированный хостинг (jira требует для работы java). Я никогда не зацикливаюсь на вопросе оплаты продукта и считаю, что деньги должны делать деньги. То есть затраты на хорошую систему issue tracker окупятся очень быстро, а если позволят в корне избежать “разборок” с недовольным клиентом или проблемы поиска “крайнего” внутри коллектива – то и говорить больше не о чем. Тем не менее, JIRA действительно сложно установить и настроить, часто ее функциональность не нужна в полном объеме. Может быть, разрабатываемый вами проект является не коммерческим, и вы хотите использовать issue tracker для того, чтобы пользователи вашей программы могли сообщать об ошибках, предлагать и голосовать за новые “фичи”. Тогда, действительно, использование дорогостоящей и требовательной к хостингу системы будет избыточным. Нам нужен инструмент бесплатный, готовый запуститься и работать с приемлемой скоростью на самом дешевом хостинге (читай, быть написанным на php). Но при этом нужна развитая функциональность, наличие средств создания расширений (плагинов) и развитое сообщество, так, чтобы если у вас возникнет проблема, не остаться с ней наедине. И такой инструмент есть – это mantis. Откровенно говоря, количество issue tracker систем очень велико. Сравнительная таблица различных issue tracking систем на страничке википедии сайт занимает с добрый десяток экранов. В своей практике я работал только с двумя написанными на php продуктами класса issue tracker – это flyspray ( сайт и тема сегодняшнего материала – mantis ( сайт ), и впечатления остались самые положительные. Но давайте ближе к делу.

Установка mantis не требует никаких специальных знаний: не нужно создавать и вручную править какие-то конфигурационные файлы. Все делается автоматически благодаря скрипту-инсталлятору, встроенному в скачанный с сайта сайт дистрибутив mantis. Теперь при попытке первого входа внутрь mantis приложения появится диалоговое окно мастера установки, где вас попросят ввести параметры подключения к базе данных mysql. Как вариант вы можете использовать для хранения данных базу microsoft sql server, oracle, ibm db2 или postgres. После завершения установки нужно удалить папку “admin” в каталоге с mantis и можно заходить в приложение, используя имя “administrator” и пароль “root”. Сразу после входа зайдите в меню “My Account” и замените пароль администратора. Сразу скажу, что внешний вид mantis не впечатляет (цветовая гамма и интерфейс в стиле минимализма), развитой системы скинов нет, исходники написаны ужасной “лапшой”, смешивающей фрагменты html или куски логики на php, да еще и без комментариев. Но тем не менее, работать очень удобно.

Начнем мы с того, что создадим несколько новых пользователей и назначим им права доступа. Для этого заходим в меню “Manage”, затем в подменю “Manage Users”. Там мы должны увидеть табличку с перечнем всех пользователей, зарегистрированных в mantis (изначально там будет только учетная запись administrator-а). Для создания нового пользователя жмем кнопку “Create New Account” и заполняем поля формы регистрации. Первые два из них: имя пользователя, используемое для входа внутрь mantis, и реальное имя пользователя (ФИО) должны быть уникальными для всех работающих с mantis. Затем вы указываете адрес электронной почты. Адрес обязателен, так как именно на почту придет сообщение о том, что пользователь был зарегистрирован и там же будет приложена ссылка, зайдя по которой на сайт mantis вы должны будете завершить процедуру регистрации и указать свой пароль. Следующий важный параметр при создании нового пользователя – назначение его глобального уровня доступа. То есть у каждого пользователя есть два набора прав – первый набор привязан к конкретному проекту, а второй является общим для всех проектов. Возможные значения прав — это viewer, reporter, updater, developer, manager, administrator. Собственно, из самих названий ролей уже можно понять, какие функции должны выполнять соответствующие пользователи (роль viewer обычно отдают внешнему заказчику, который может просматривать задания, но изменять их не должен). Но если вас интересует конкретная таблица, где перечислено то, какая роль что может и не может делать, то выберите в главном меню mantis пункт “Manage ->>> Manage Configuration”, затем в подменю “Permissions Report” вы можете увидеть текущие настойки прав, а в подменю “Workflow Thresholds” можете редактировать уровни доступа ролей.

Каждый из пользователей, кого зарегистрировал администратор, может после активации учетной записи по ссылке, присланной на e-mail, зайти в меню “My account” и выполнить детальную настройку своей учетной записи. Прежде всего настраивается список извещений, которые будет получать пользователь (при создании новой задачи, переоткрытии, закрытии заданий и т.д.). Приятно, что mantis поддерживает локализацию интерфейса, так что каждый из пользователей может выбрать свой язык интерфейса mantis (есть поддержка русского). Для тестеров полезным будет зайти в настройках учетной записи на закладку “Profiles”. Дело в том, что когда qm создает репорт об ошибке, то обязательно нужно указать то, как ошибку воспроизвести и на каком окружении она проявляется, т.е. версию операционной системы, какие-то установленные библиотеки и т.д. Для того чтобы эту информацию не заполнять каждый раз заново, mantis предлагает создать набор профилей (каждый профиль состоит из платформы, названия операционной системы, ее версии и примечания). Затем, когда заводится баг, то репортер просто выбирает из падающего списка одну из существующих платформ.

После создания пользователей самое время перейти к созданию проектов. Для этого администратор должен зайти в меню “Manage”, затем подменю “Manage Projects”. На появившейся странице будет виден список зарегистрированных проектов, а при нажатии на кнопку “Create new project” появится диалоговое окно, в котором нужно указать основные свойства нового проекта (см. рис. 1). Единственное, на что здесь следует обратить особое внимание – это поле “Upload File Path”. Всякий раз, когда к создаваемому заданию (issue) будет добавляться какой-то файл (например, скриншот с изображением ошибки), то он будет сохраняться в указанный вами каталог. Путь к каталогу указывается абсолютно и он должен предварительно быть создан и иметь права доступа на запись. Также, создавая проект, мы должны выбрать тип ограничения доступа к нему: “PUBLIC” или “PRIVATE”. В первом случае с проектом могут работать все пользователи, а с проектами в режиме “PRIVATE” могут работать либо администраторы, либо те пользователи, которые были явно присоединены к проекту.

После создания проекта начинается самое интересное – детальная настройка проекта. Для этого мы делаем клик по названию только что созданного проекта и попадаем на страницу, показанную на рис. 2. Прежде всего нужно определить, из каких подпроектов будет состоять наш проект. К примеру, если мы разрабатываем проект текстового редактора (wordpad), то можно создать подпроекты “разработка графических элементов управления” и “создание документации”. Далее мы можем указать для проекта список категорий, к которым будут относиться создаваемые задачи, например, категория security (ограничение доступа к документам wordpad) или категория help (справочная система). Затем нужно создать список версий продукта (например, 1.0 или 2.1.5). Завершающим штрихом будет назначение к проекту списка людей, которые будут работать над проектом, с указанием того, какую роль они будут играть (настройки уровня проекта обладают приоритетом над глобальными правами доступа).

black-zorro@tut.by black-zorro.com