Распределенные системы учета ошибок
IkeОпубликовано 17.05.2008 в Статьи
С появлением распределенных систем контроля версий появились и распределенные системы учета ошибок. Самая простая — файл TODO в папке проекта, уже давно полюбившаяся многим со времен svn и в данном случае работает совсем не плохо, в отличии от монстров (например Jira). Ведь помимо разных ревизий у участников проекта добавляются проблемы с разными branch’ами, в каждом из которых могут быть свои баги, более новые, уже исправленные другими и так далее. Учитывать их обычными средствами настоящая каторга. В, и без того монструозной, Jira или Bugzilla пришлось бы добавить к ревизии branch, баги бы часто дублировались, трудно было бы отследить состояние разных веток. Текстовый файл же легко выдерживает merge и остается весьма актуальным у каждого из участников проекта. Но есть и более элегантные решения — учет ошибок распределенный как и контроль версий.
На данный момент существует уже несколько open-source систем. Одна из них Bugs Everywhere, которую я сегодня же решил опробовать на одном из своих проектов. Bugs Everywhere написана на Python’e, и работает поверх одной из распределенных VCS: Arch, Bazaar, GIT, Mercurial, RCS. Она предоставляет интерфейс коммандной строки, графический (WxWidgets) и веб-интерфейс (требует TurboGears). Технически — она создает скрытую директорию в папке проекта, где в текстовом формате хранит баги и информацию о них. В случае коммита она передает изменения вместе с кодом. В результате merge ваш коллега получит записи о багах в вашем branch’e.
Command-line session:
Устанавливаем:
bzr get http://bzr.bugseverywhere.org/be (Bugs Everywhere можно получить только посредством bzr)
cd be
sudo python setup.py install
Инициализируем директорию проекта для работы с ней Bugs Everywhere:
cd ~/YourProjectsDirectory/YourProject
be set-root
Добавляем баг:
be new ’test bug’
-> Created bug with ID 446
Добавляем комментарий так:
be comment 446 ’test bug comment’
или так:
export EDITOR=vi
be comment 446
bzr ci =)
Как и в любой другой VCS вы можете устанавливать приоритеты и назначать задания, просматривать изменения и все это для кажого branch’a. И что немаловажно, для меня, привыкшего уже к Command-Line интерфейсам, все это легко делается в коммандной строке, другие интерфейсы, говоря честно, я и не смотрел.
А Python-программистам она будет интересна как поле для модификаций — проект очень компактный, код красивый и компонентный, его удобно модифицировать и развивать под свои нужды.
Я надеюсь работа над этой прекрасной системой не остановится, уже сейчас есть люди готовые написать для нее Trac backend, возможно появится интеграции с редакторами (я уже подумываю, а не сделать ли мне bundle к своему TextMate), ведь наблюдая за тем как активно люди сейчас начинают пользоваться распределенными системами контроля версий, такому проекту можно предсказать только светлое будущее. Сразу скажу, что в своих проектах я уже начал пользоваться Bugs Everywhere в тестовом режиме.
Если вы знаете другие подобные системы, и готовы о них рассказать, буду очень рад.
Более подробно узнать о распределенных системах учета багов можно в статье Distributed Bug Tracking, откуда о них собственно я и узнал.
Загрузка ...Понравилась статья? Подпишись на обновления по RSS, E-mail или наш Twitter.
Я с ним одно время работал. Пришел к выводу, что он слабо полезен в случае множества feature branches и множества разработчиков. Trac как централизованная база багов лично для меня гораздо лучше.
Под виндой его тоже можно запустить, правда нужно слегка попотеть. Для получения кода установите плагин для bzr с названием win32symlinks, затем нужно сделать небольшой batch-файл для запуска питон-скрипта be. Плюс нужна утилита из комплекта Win32 SDK uuidgen. Вобщем у кого будут проблемы с ее установкой-использованием, можете обращаться с вопросами в гугл-группу ru_bzr, я помогу.
У одного централищованного trac я вижу только одно приемущество — это возможность видеть общую картинку для всех бренчей. Исключается возможность что кто-то уже пофиксил баг не назначенный на конкретного человека в другом бренче, а у тебя он висит. Но эта проблема решаема, как минимум тремя разными способами — назначать баги, чаще мерджить, смотреть на баги в отдельном девелопмент-бренче периодически.
Меня be привлекла простотой и command line интерфейсом — высока вероятность что я ей смогу пользоваться не тогда когда надоест, а регулярно. Потому что когда разработчиков мало, и проекты не очень большие интерфейс гмейла лучше интерфейса большинства багтреккеров.
Еще мне очень интересно будующее таких систем. Сначала распределенные системы версий были тоже не очень удобны многим, но смотря за темпами миграции можно сказать что развиваются они очень неплохо, я вот сам пользуюсь bzr в собственных проектах и git для рабочих. Я думаю в ближайшее время два-три решения для распределенного учета багов вполне могут появиться, в противном случае я ошибаюсь и эта идея совсем гнилая.
Идея распределённого учёта багов неплохая, но такая реализация, когда на каждый баг и комментарий к нему делается отдельный коммит… В небольших закрытых проектах это, наверное, имеет право на жизнь. Но если посмотреть на, к примеру, Django – 7539 changeset’ов и 7257 тикетов (на данный момент). Выходит, что с такой системой количество changeset’ов было бы просто ужасающим. Вообще, такая реализация к open source совершенно не подходит. Но идея, повторюсь, хорошая.
А вот тут я несколько не понял:
“Учитывать их обычными средствами настоящая каторга. В, и без того монструозной, Jira или Bugzilla пришлось бы добавить к ревизии branch, баги бы часто дублировались, трудно было бы отследить состояние разных веток.”
Что-то я не очень понял, почему в jira или bugzilla с этим проблемы. Ведь branch – это просто часть версии, версии эти системы поддерживают. То, что нужно разные баги для разных веток создавать – это даже плюс, т.к. заниматься их исправлениями могут разные люди, будет отдельно учитываться время работы по версиям и т.п. Про проблемы с отслеживанием состояния веток – вообще не понял, вроде все просто.
идея может и не гнилая, но стиль работы с багами меняется полностью. поддержу Всеволода с его замечанием относительно количества фиксаций. В BE к багам можно добавлять комментарии — и каждый комментарий — это тоже будет новая фиксация! Изменил статус бага — новая фиксация. (Аналогичный бред в hg, где каждое изменение тэга выливается в отдельную фиксацию).
Т.е. на больщее чем замена файлика TODO, который ведет для себя конкретный разработчик, такие системы слабо подходят. Пробуйте ее в жизни, несколько месяцев-год, может у вас выработается эффективная стратегия работы, тогда проапдейтите эту статью, или напишите новую.
Однако я вижу только один путь не загромождать основную историю проекта фиксациями изменений в багах — это вести отдельную ветку для базы багов и ее часто объединять с другими и фиксировать часто.
Однако для интеграции с основным проектом тогда понадобится что-то типа svn:externals. А эта фишка работает нормально только в git. В hg она кривая, а в bzr вообще в зачаточном положении. Так что увы и ах. Мой выбор — trac.
Критика централизированных bug-tracking систем (Jira, bugzilla) не выдерживает никакой критики
Добавляются нужные поля (бранчи, версии, ревизии если они нужны), эти поля делаются мультиселектными и вуа-ля – даже дублировать ничего не надо. Просто помечаешь на каких версиях/бранчах воспроизводится баг, и на каких его нужно чинить. “Вы не любите кошек? Просто не умеете их готовить!” (С)
По сравнению с описанным в статье подходом есть большой плюс – в любой момент можно сделать выборку сквозную по всем версиям / бранчам или их комбинациям, что как я полагаю, будет намного медленнее как при работе с TODO файлами, так и с децентрализированной системой (нужно пройти по всем веткам).
Распределенность полезна ИМХО только в случае сложности с установкой централизированного bug tracking server, т.е. при очень дистрибьютед среде.
1. mgu, Максим Крамаренко:
То есть в общем-то нет ничего криминального в любом из них, кроме того что баги в них не заносят. Вся эволюция багтреккинга это впервую очередь облегчение работы с ним. Версии работают только для приложений в цикле build, test, deploy, длительностью больше дня. Когда в день по 50-100 changeset’ов и одна-две выкатки на сервер, определение версии уже становиться бесполезной условностью. То же самое и с ветками — распределенные системы можно использовать как svn с хорошим merge и простым созданием веток, и тогда отдельное поле branch работает, а можно работать по одному из распределенных сценариев, и занося каждый branch в багтреккер можно получить огромную кучу мусора, которая в распределенном багтреккере решается в момент слияния (после каждого слияния веток мы в идеале имеем баги только итоговой ветки) — какая тут сквозная выборка, если половина багов — дубликаты.
Основная проблема любого баг-треккера, это то, что им не пользуются
Когда я смотрел на распределенный багтреккинг, я смотрел с позиции, когда багтреккинг то не особенно и нужен. Да, это малая закрытая комманда. И это хорошо — потому что приживается инструмент, который максимально удобно использовать, писать в jira никто бы не стал, даже формочки в простом багтреккере бы путали с окном гмейла, возможно по этому мне так понравился инструмент в котором мне не надо заполнять поле версии, ветки, даже указывать человека, а достаточно лишь занести баг и ввести bzr merge & bzr push
Ike,
Похоже. мы говорим о разных вещах. Я и Максим – о дефектах или change request, которые достаточно долгоживущи (более одного дня, иногда месяцы и годы) и могут заводиться не только непосредственно разработчиками, но и QA или даже конечными пользователями.
Заметка же, судя по всему, касается исключительно пометок a la “todo”, которые разработчики оставляют себе как памятку. Их действительно не имеет смысла трекать вместе с багами и они вполне могут находиться в коде или вместе с кодом в бранчах (хотя пропускать их в основную и релизные ветки, ИМХО, нежелательно – лучше оформлять дефект или change request на будущее, но это уже зависит от процесса )
Следовало бы четко определить область применения, чем разбрасываться необоснованно генерализированными утверждениями.
Очень спорное утверждение, скажу даже “ложь” в булевом смысле
Во всех более или менее серьезных коммерческих и нет проектах, которые мне приходилось наблюдать или участвовать, bug tracking (а еще лучше – в более общем смысле – change request) были налажены.
Если нет версий – то и не нужно их трекать
значит есть просто bug и статус – открыт или закрыт. ну может еще номер билда, в котором обнаружен.
Заносить нужно то, что имеет смысл. Скажем, если я в своем личном бранче обнаружил или создал баг, то незачем трекать какой именно это бранч. Интересует воспроизводимость в общих активных ветках, которых немного (в Вашем случае – одна, и значит даже это не интересует). Опять же, совершенно непонятно откуда в Jira возьмутся дубликаты при мерже; максимум – в поле “бранч” будет вместо одного выбранного значения два, что не проблема – и вот тут-то я смогу сделать свою “сквозную” выборку
Надо было сразу так сказать:)
Мы пользуемся “монстром” JIRA и довольны. Те недостатки JIRA, которые описывает автор, при грамотном использовании JIRA вообще не существуют. К тому же эта система “…в текстовом формате хранит баги и информацию о них”, а мне почти к каждому багу приходится цеплять скриншот, лог, конфиг и т. п., есть ли такая возможность в ВЕ? Также в JIRA можно полностью проследить всю историю бага (коменты, закрыли, открыли снова, отредактировали, переназначили и т. д.), что очень важно. Конечно, для небольших проектов JIRA может быть избыточна(хотя я не уверен в том, что масштабирование в меньшую сторону вызовет сложности).
Налажены и “ими пользуются” — понятия разные. Багтреккером пользуются в основном тестеры — потому что это их основной способ отчетности, неравнодушные менеджеры и разработчики (кто-то периодами, по-настроению, кто-то регулярно, но точно не все, если в компании более одного-двух), или зануды (”сяду-ка я напишу 30 багов, пусть подавяться”) — классификация упрощенная, но я не видел и не слышал ни об одной более-менее крупной компании где bug&issue tracking был полностью централизован и являлся основным средством постановки задач подавляющему большинству разработчиков.
А если в соседнем есть функционал который перекрывает эти баги или их там уже пофиксили, в то время как в основном этих фиксов/изменений нет?
Надо сказать что с такой позиции смотрит подовляющее большинство разработчиков и менеджеров.
Даже когда речь идет об очень не маленьких проектах.
Да и сразу отвечу на вопрос ниже — нет, конечно картинку привязать на данном этапе к задаче нельзя. Я и не рассматриваю be как готовую замену Jira или какому-либо иному багтреккеру. На мой взгляд это очень интересное и перспективное направление развития. В be мне нравиться простота — это именно утилита, а не программа, в том числе и простота модификации
. Вполне возможно что это направление будет развиваться, и скоро мы увидим полноценные и интересные VCS построенные по такому же принципу
Спор местами начинает напоминать глухого со слепым, но не удержусь
В моем ответе читай “налажены и успешно используются”
На счет более крупных компаний с централизацией багосистемы не скажу – давайте поговорим о том, в чем компетентны. Скажем, работа над одним продуктом и комманда до 10-20 человек. Приходилось участвовать в слиянии change requests – specifications/ bugs / future plans в одну систему. Стало намного проще, как с точки зрения product management в планировании ближайших релизов так и с более приземленного уровня отслеживания зависимостей. И этот случай не един. Если говорить о действительно больших организациях (более 100 человек, много проектов), то тут польза от централизированной единой системы – в унификации администрирования и подходов, при известных минусах, но это ИМХО совершенно не относится ни к поднятой теме ни к комментариям.
На счет основного средства постановки задач – я не совсем понимаю, о чем речь. Спецификации? Их можно держать в Issues, если очень хочется, в моем примере это заменено на общение с заказчиком.
Никаких проблем. Что-то типа: будет комментарий о починке в этой соседней ветке и баг будет взят на себя починившим до мержа в общую ветвь, что должно быть достаточно скоро в случае короткоживущих веток, или это будет по полной программе оформленно QA в случае фикса в одной из долгоживущих веток.
Как раз сложнее представить себе как в распределенной системе я узнаю что кто-то пофиксил некий баг, не слившись с его веткой.
В организациях, описанных Вами выше ( тестеры багят для отчетности, остальные – из вредности ) – вполне может быть. Лично я стараюсь избегать подобные среды. Есть много других. А в этих проблема не в инструментах, ИМХО.
А если вообще по индустрии – потрудитесь подкрепить свои слова фактами. Хотя бы корректно сформулированным опросником на сайте (хотя выборка и не совершенна).
В завершениие еще раз хотелось бы отметить, что описанный подход хоть и представляет собой интерес в качетве дополнения, но не может, судя по всему, в целом еще заменить традиционный bug/issue tracking механизм в более или менее серьезной разработке с участием 3х и более лиц, и тут я уверен – со мной согласится подавляющее большинство разработчиков, менеджеров, специалистов по качеству, и особенно клиентов и пользователей
Это совершенно нормальная среда, честно — я не очень верю людям которые говорят что им нравиться работать, а любое формализованное действие воспринимается как препятствие, как бы кого-то не пытались переубедить умные книги, воспринимается часто даже опытными разработчиками, и коллективами где уже есть устоявшиеся инструменты. Честно — подкреплять фактами мне лень, никто же не признается (багтреккинг это модно, “ты не читал “Путь камикадзе” — ты лох и так далее), “Ну подумаешь две задачки в почте” — тоже распространенное явление. Это все вполне банальная психология. Увидев баг человеку трудно его зарепортить, лень занести задачу — проще письмо написать или подойти, “сегодня мы торопимся поэтому обойдемся без формальностей”. Я не верю в идеальный мир, следовательно не поверю ни в одну идеальную компанию где все счастливо работают с багтреккером, формализуют процесс и так далее. Собственно самым интересным для меня в данном контексте было краткое общение с Костей Коломейцем из Яндекса, который делает нечеловечный инструментарий — человечным. Пожалуй об инструментарии я напишу отдельно.
Скажу только что в нескольких средних проектах, в которых я работал и работаю багтреккером вообще почти не пользуются. На это были и есть разные причины, и не скажу что такой подход неэффективен. Все зависит от конкретных условий.
а конкретно про be — это очень забавный инструмент. Не массовый, но будет здорово если он поможет кому-то.
Я не читал “путь камикадзе”. И не собираюсь. Ходил сам
Баг треккинг – это давно уже не мода (если когда и была – я на своем веку не застал), а удобный и зачастую необходимый инструмент. Заметьте, никто не говорит о том, что все нужно заносить в эти “тяжеловесные системы” – ведь треккинг issue и их очередей – это накладные расходы. Я считаю вполне нормальной ситуацию
– пусть эксперт решает можно ли починить быстро или оформить по правилам. Баги – это не самоцель. Никакой формализации или идеализации – все в рамках прагматического подхода. По-этому, кстати, я в самом первом своем ответе провел речь между долго- и короткоживущими issues.
Для меня как раз более идеалистичным выглядит случай, когда действительно можно вполне обойтись без расходов на баг треккинг – это когда система очевидна и доступна пониманию, дефекты обнаруживаются, доносятся и чинятся быстрее, чем имело бы смысл их отслеживать, и скорее всего наличествует хорошая страховка в виде автоматических тестов. Увы, в подавляющем числе случаев это наблюдается на самых начальных этапах разработки
На мой взгляд самое плохое это конфликт двух систем — можно бить по рукам за не использование багтреккера и со временем все будут кряхтеть и заносить в него задачи или наоборот от него отказаться. Но когда половина задач кусками в почте и IM, а вторая половина в багтреккере становиться работать (по собественному опыту) неприятно. В общем-то все это набор частных проблем которые можно решить посредством усовершенствования тех же багтреккеров, чтобы занести баг было удобнее написания письма, и подойти.
У меня нет метрик, к сожалению, но мне радостно что приходиться дело иметь именно с таким проектом, и не сказать чтобы он такой уж маленький
Куски из почты и IM тоже вполне реально заносить в багтрек. Заодно и внятно описать суть, которая может
утонуть в офисной переписке.
Кроме багов, есть еще и фиче-реквесты. Их тоже неплохо вести через багтрек.
У нас все идет через багтрекер (об этом легко догадаться по сайту конторы
, но причина этого – не в битье по рукам, просто у нас запрещено править багу, если ее нет в багтрекере и этот разработчик не выставлен ответственным.
Причины:
- у разработчиков нет “своего” кода, в котором программист может делать что хочет – задачи часто назначаются произвольно (на это тоже есть причины). Поэтому делать что понравилось – большие шансы получить конфликты при покладке в SVN.
- через багтрекер ведутся ежедевные отчеты. Нет задачи – некуда отчитываться.
- при коммите нужно указывать номер исправленной баги – без баги в багтрекере указывать нечего.
При таком подходе вероятность того, что разработчик будет тайно фиксить ошибки, которых нет в багтрекере примерно равна вероятности того, что сантехник из ЖЭК-а будет забесплатно и тайно от всех ходить по квартирам и ремонтировать краны т.к. “дошел слух, что протекает”. Причем сантехников за это никто по рукам не бьет – я точно знаю
Если багтекер в достаточной степени интегрирован в процесс, то проблемы использования/не использования не возникает.
Это действительно спор слепого с глухим, где каждый прав, потому что исходит из своего личного опыта. Тем более очень смешно читать, что багтрекинг никто не хочет и не будет пользовать в свете совсем недавней статьи “Об эффективных баг-репортах” http://www.developers.org.ua/archives/egorfine/2008/04/03/effective-bug-reports/
Главная мысль статьи — что людей нужно учить и принуждать правильно пользоваться системой. Поэтому убеждать, что те, кто не пользуется централизованной базой багтрекинга — правы — это перебор. Скажу даже больше — это все фигня. Для долгоживущих проектов нужна централизованная база.
При этом я с успехом пользуюсь bzr для управления моим кодом, и централизованной базой Trac.
За последнее время я понял, что децентрализованные системы не живут сами по себе. Все равно должен быть центр, пусть он становится социальным, а не навязываемым trunk как в svn, но он должен быть. А с багами — это архиважно. Цитируя одно из высказываний выше: “как в системе BE я узнаю, что добавлен новый баг или починен какой-то старый, если я не объединял свою ветку с веткой другого разработчика? а если он вчера завел/починил баг, а сегодня уехал в отпуск?”
Кстати, есть ещё неплохая система Ditz. Меня подкупила симпатичными статическими HTML-отчётами с детализацией по задачам и релизам.
Её ещё во втором апдейте статьи Distributed Bug Tracking похвалили. Я тоже двумя рукам за