- PVSM.RU - https://www.pvsm.ru -
Настоящий IT-шник всегда любит сварить «кашу из топора». А если этой кашей еще и получается вкусно накормить коллег, то выходит вообще замечательно.
По долгу службы мне постоянно приходится сталкиваться с различными инсталляциями bug и issue-трекеров (далее просто баг-трекеров) и среди них попадалось довольно много нестандартных решений. Что-то мне приходилось разворачивать самому, что-то я «подсмотрел» у клиентов, но поделиться наблюдениями было бы полезно.
С этой темой я уже выступал [1] на конференции SQADays [2], но для тех, кому лениво смотреть 18 минут видео, все будет кратко расписано в статье.
Итак, для чего вообще может понадобиться нестандартно использовать баг-трекер? Причины для этого могут быть две:
Примеры, которые пойдут дальше, взяты из реальной жизни. Но успешное внедрение у кого-угодно никак не означает, что и у вас все пойдет как по маслу. Не забывайте думать, пробовать и советоваться со старшими товарищами.
Ну и сразу попрошу прощения, что частенько упор пойдет на использование JIRA [3] (можете кинуть в меня помидор), т.к. эту систему я использую на повседневной основе, но и другие баг-трекеры не были забыты — практически все нижеописанное можно сделать и с их помощью.
Наиболее частым, не совсем стандартным, применением баг-трекера, которое мне приходилось наблюдать, было использование его в качестве HelpDesk-а в службе технической поддержки.
Из плюсов такого применения можно отметить удобство связывания обращений в HelpDesk и багов, по ним заведенных (интеграции с HelpDesk-ами с каждым днем хорошеют, но идеала все нет), и отсутствие необходимости учить техподдержку работать с двумя системами. Но нужно понимать, что такая система будет чуть менее удобна, чем отдельный HelpDesk, и если вам приходится работать с большим количеством обращений, большинство из которых решается службой поддержки самостоятельно, то лучше смотреть на отдельную HelpDesk-систему.
Ближе к делу. Как такую систему можно настроить?
Сначала требуется обеспечить возможность приема обращений по email. Благо многие баг-трекеры умеют создавать заявки из электронных писем:
Использование этих плагинов/обработчиков позволяет парсить письма, сохранять тему письма в теме созданной заявки, аттачить вложения из письма к заявке, привязывать ответные сообщения к соответствующим заявкам.
Но даже если вы не планируете разворачивать у себя HelpDesk, попробуйте использовать создание и комментирование заявок через email в повседневной работе. Некоторые находят это очень удобным.
Дальше нужно обеспечить принятие заявок через веб. Обычно в баг-трекере можно:
Для JIRA отдельно стоит отметить плагин Issue Collector [8], который позволяет настроить удобные формы обратной связи для последующего размещения у себя на сайте.
К сожалению, плагин еще сыроват и не во всех случаях может надежно работать.
Наличие службы поддержки обычно подразумевает и наличие SLA (Service Level Agreement [9]), по которому вы обязаны решать инциденты за строго определенное время. А для искоренения забывчивости администраторы, с подачи руководства, настраивают всякие напоминалки:
Согласования, отфутболивания, заявки, многоуровневые иерархии сотрудников, что может быть лучше… для автоматизации? На самом деле, автоматизация каких-то бюрократических моментов организации, если и не помогает сделать их проще, то уж прозрачнее так точно делает.
Доводилось видеть баг-трекеры, с помощью которых делали согласование закупок оборудования, отслеживание бюджета проекта, работу с документами и т.п.
В основе такой кастомизации обычно лежит создание своего Workflow — жизненного цикла заявки. Т.е. какие состояния у заявки есть и какие переходы могут быть между ними. Кроме того, благодаря настройке прав доступа отдельные переходы можно разрешить только для специально обученных ответственных товарищей.
Помогает создание своего workflow и в ежедневной рутине разработчика. Например, могут быть введены новые промежуточные состояния для задач вроде «в тестировании» или «идет приемка заказчиком».
Использование своего workflow обычно неразрывно идет с созданием так называемых custom fields и новых типов заявок. Custom fields могут помочь в хранении любой дополнительной информации:
Новые типы заявок (например, «согласование документа», «закупка», «проектирование» или «тестирование») позволяют не только сделать процесс работы более наглядным, но и привязать к каждому типу заявки отдельный Workflow. Так если для задачи «разработка» имеет смысл ввести состояние «тестирование» в жизненном цикле, то для задачи «дизайн» такое может и не понадобится.
Баг-трекер это не только ценный инструмент, но обычно и система почтовых нотификаций, в него встроенных. И эти нотификации можно использовать себе во благо для создания почтовых рассылок внутри организации. Рецепт прост:
Вам определенно следует позаботиться о контроле за ресурсами, если одни и те же сервера часто одновременно используются для различных нагрузочных тестов, либо два сотрудника одновременно пытаются забрать один и тот же iPad в командировку для демонстрации.
Воспитывать совесть у коллег с помощью баг-трекера сложно, но повысить уровень организации можно. Рецепт:
Естественно, никто не может запретить человеку забрать ресурс и «не отметиться в системе», но с помощью доброго слова и удобного инструмента можно сделать больше, чем с помощью одного доброго слова.
Довольно распространенную функцию голосования за реализацию тех или иных заявок тоже можно использовать себе на благо. Если вы задались вопросом «куда пойти на корпоратив» или «что подарить директору на день рождения», то можете смело использовать баг-трекер (убедитесь только, что директор им не пользуется :). Рецепт:
JIRA и Bugzilla имеют встроенную функцию для голосований. Для Redmine есть плагин [17].
Есть любители использовать баг-трекер в качестве системы для хранения набора регресcионных тестов, которые нужно выполнять вручную на каждой очередной версии продукта. Сам я не фанат такого способа, но раз люди используют, то что-то в этом есть. Рецепт:
Плюсы такого решения: очень удобно из тестов ссылаться на заявки/баги в баг-трекере, нельзя закрыть версию, в которой есть «незакрытые» тесты. В целом может быть не так удобно, как специализированная система для тест-менеджмента.
Кроме возможностей по настройке баг-трекеров (а все предыдущие рецепты по сути настройки) часто есть возможность расширить функциональность баг-трекера и программно.
Все основные баг-трекеры имеют интерфейсы для удаленного доступа, которые можно использовать для какой-то своей автоматизации. Например, автоматически постить заявки по каким-то событиями или из внешних систем.
Кто не хочет заморачиваться с программированием, может использовать для автоматизации клиенты командной строки:
Для разжигания холиваров скажу, что самый развитый клиент у JIRA :)
Ну а если вам вообще ничего не хочется делать самому, то стоит поискать уже готовые плагины для своего баг-трекера:
Опять-таки здесь JIRA впереди планеты всей. В основном благодаря экосистеме для разработчиков плагинов, которая при должном уровне подготовки позволяет очень здорово кастомизировать поведение JIRA и добавлять всякие «полезности» и «свистелки».
Пару мыслей, которые я хотел донести до слушателей на SQADays и до читателей на Хабре:
А в комментариях буду рад увидеть какие-то нестандартные использования баг-трекеров, которые попадались Хаброжителям.
Спасибо!
Автор: cr0ck
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/diy/7980
Ссылки в тексте:
[1] выступал: http://vimeo.com/40679676
[2] SQADays: http://it-conf.ru/ru/content/465.htm
[3] JIRA: http://www.atlassian.com/software/jira/overview
[4] Mail Handlers: http://confluence.atlassian.com/display/JIRA/Creating+Issues+and+Comments+from+Email
[5] Jira Enterprise Mail Handler: https://plugins.atlassian.com/plugins/com.javahollic.jira.jemh-ui
[6] EmailReporting Plugin: http://www.mantisbt.org/wiki/doku.php/mantisbt:emailreporting
[7] email_in.pl: http://www.bugzilla.org/docs/3.0/html/api/email_in.html
[8] Issue Collector: https://plugins.atlassian.com/plugins/com.atlassian.jira.collector.plugin.jira-issue-collector-plugin
[9] Service Level Agreement: http://ru.wikipedia.org/wiki/SLA
[10] относительно простое решение: http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System#JIRAasaSupportSystem-SLAs
[11] Whinning: http://www.bugzilla.org/docs/tip/en/html/whining.html
[12] плагины и скрипты: http://www.mantisbt.org/wiki/doku.php/mantisbt:issue:7721
[13] можно докопаться: https://answers.atlassian.com/questions/44947/jira-5-removed-the-steps-view-for-editing-workflows
[14] "подкрутить": http://www.bugzilla.org/features/#custom-workflow
[15] покопаться в коде: http://www.mantisbt.org/manual/manual.customizing.mantis.customizing.status.values.php
[16] виде таблички: http://www.redmine.org/projects/redmine/wiki/RedmineIssueTrackingSetup
[17] плагин: http://www.redmine.org/boards/3/topics/5506
[18] REST, SOAP, XML/JSON-RPC: https://developer.atlassian.com/display/JIRADEV/JIRA+Remote+API+Reference
[19] MantisConnect SOAP: http://sourceforge.net/projects/mantisconnect/
[20] REST: http://www.redmine.org/projects/redmine/wiki/Rest_api
[21] XML: http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService/Server/XMLRPC.html
[22] JSON: http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService/Server/JSONRPC.html
[23] JIRA CLI: https://plugins.atlassian.com/plugins/org.swift.jira.cli
[24] Trac-admin: http://trac.edgewall.org/wiki/TracAdmin
[25] Bugzilla PyBugz: http://code.google.com/p/pybugz/
[26] Redmine-cli: https://github.com/textgoeshere/redcmd
[27] более 400 плагинов: https://plugins.atlassian.com/plugins/app/jira/featured?cost=all
[28] более 230 плагинов: http://www.redmine.org/plugins
[29] около 50 плагинов: http://trac.edgewall.org/wiki/PluginList
[30] 25: http://www.mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins
[31] плагинов: http://git.mantisforge.org/
Нажмите здесь для печати.