Возникла необходимость поставить в конторе систему ведения ошибок. Что-то вроде bugzilla, jira, etc
Тема мною совсем не копана, поэтому хочу спросить у более опытных: в чем основные преимущества джиры, багзиллы перед аналогами?

Их очень очень очень очень много...
из "известных" кроме JIRA отмечу еще TrackStudio и FogBugz

Проблема в том что вы сами должны четко представлять чего вы хотите от bug/issue tracking system иначе выбрать будет просто нереально. Я когда-то довыбирался до того что 8 месяцев принимал активное участие в разработке http://sourceforge.net/projects/trackplus...

Совет один - напишите на бумажке что вам от системы надо и выбирите систему которая строго удовлетворяет вашим нуждам. Большие тракеры такие вещи в себе что недели уходят на то чтоб понять как ими пользоваться а уж людей обучить людей...

Использование распространенного трекера - это правильно. Несколько лет назад был некий бум написания собственных систем контроля дел или ошибок, сейчас вроде бы все понимают, что знание интерфейса мейнстримовой системы  - это как знание языка типа английского. Т.е. изучив, например, интерфейс и понятия, скажем, Bugzillы - у вас не будет проблем с подачей и анализом багов в десятке (а то и сотне) опенсорсовых или просто открытых проектов. Это при том, что возможно, дизайн вам покажется убогим, а ее внутренности (если захотите править - ужасными), и вполне возможно, что за несколько месяцев вы родите с нуля систему, которая полностью удовлетворит вас. Но это будет как эсперанто - у всех ваших коллег все равно не удовлетворишь по эргономике и дизайну, к тому же будет влом изучать систему, знание которой не повысит их (сотрудников) рыночную стоимость.

Важно только понимать необходимость связи системы "issue"-trackinga с остальными системами поддержки разработки - системой контроля версий, системой документирования, остальными хранилищами артефактов.

Далее надо понять, готовы ли вы например платить, скажем пять кусков (Jira) и требовать сопровождения от производителя или вам интересно поковырятся самому, много ли у вас проектов, собираетесь ли вы учитывать только ошибки или задания тоже, насколько легким будет переход с текущих технологий.

Например, если бы была небольшая новая компания - я бы рекомендовал поставить какой нибудь softwareforge типа Trac (т.е. чтобы сразу была и вебподдержка репозитария, и форумы/вики-системы или иной CMS и т.п.) в одном флаконе.

Если компания здоровая - то тут уже надо думать о стратегии внедрения, это разговор нетелефонный.



 

Trac очень удобен. 

Trac наверное удобен. многие хвалят, но... я использую Windows, не знаю Python, никогда не администрировал Apache, не имею не малейшего представления что такое ClearSilver & SQLite... когда какое-то время назад я ткнулся в инструкции по установки и абгрейду Trac, я понял что мне искренне жалко своего времени и что я не буду его убивать на то чтобы разобраться в этом. я готов тратить время на то чтобы систематизировать и отслеживать ошибки и проблеммы, но не на установку системы для систематизации и отслеживать ошибок и проблем. 

Если есть деньги и нет времени, то Jira.
+ удобная
+ не торозит
+ легко настраивается
+ как следствие - широко используется
+ постоянно развивается
- стоит денег, но это больше вопрос порядочности/жирности компании    

JIRA - а если еще в сочетании с Confluence использовать, то работа ваще превращается в праздник!  

Кто может сравнить TrackStudio vs. JIRA на предмет интеграции с SVN.
Контора хочет делать привязку багов к коду(как это например реализовано в StarTeam).Плюс иметь API для интеграции со своим добром.
TrackStudio вроде как дают даже сорцы, если проплачено за Ент.версию.
Спасибо заранее за отзывы.
 

1) В TrackStudio 3.2.x интеграция с SVN сделана на основе триггера, который вызывается при commit-е и вносит информацию в TrackStudio через SOAP API. Главный недостаток - способ сложный в настройке.
2) В TrackStudio 3.5 (бета должна быть доступна в течении 2-3 дней, релиз - в течении нескольких недель) интеграция с SVN будет в точности как в JIRA (на основе javasvn), разницы там не будет никакой.

И TrackStudio, и Atlassian дают сырцы, но в случае с TrackStudio их можно не брать :-) и прилично сэкономить. Реально исходники для TrackStudio нужны гораздо реже, чем для JIRA т.к.
- система сама по себе более гибкая и бОльшую часть функциональности можно настроить прямо из web-интерфейса. 
- в TrackStudio используются не плагины, а скрипты. Скрипты проще писать и отлаживать, можно задавать разные скрипты для разных проектов, для инсталляции скрипта не нужно перезапускать систему, компиляция тоже не нужна. Главный минус - плагины более функциональны, особенно если  дело касается изменения интерфейса.

Сравнение TrackStudio и JIRA с пристрастием тут:
http://www.trackstudio.ru/products-comparison.html
 

Мы не пробовали JIRA но мы всерьез пробовали TrackStudio. Полагаю что они концептуально и функционально близки. был выделен человек который посвятил 2 недели на то чтобы досконально разобраться и принять решение подходит оно нам или нет. Вывод - мощно, гибко в освоении не тривиально, для нашей команды в 10 человек смысла не имеет - слишком наворочено для наших нужд... . 

Вы правы, все так и есть. Но за разницу в цене года саппорта и апгрейдов ($2400 у JIRA против $300 у TrackStudio) в наших краях можно посадить 2-х человек чтоб они в течении месяца изучали особенности TrackStudio и рассказывали остальным, еще и деньги останутся   

Это сообщение отредактировал(а) maximkr - 26.4.2006, 17:04

maximkr,  ALKS,
Господа, спасибо большое за обзор.

>> - в TrackStudio используются не плагины, а скрипты. Скрипты проще писать и отлаживать, можно >>задавать разные скрипты для разных проектов, для инсталляции скрипта не нужно перезапускать >>систему, компиляция тоже не нужна.

А что за скрипты там используются: внутренних кастомизированный язык? Или что-то стандартное, типа перлухи?
  

Beanshell, т.е. синтаксис Java-подобный. Какого-то специального API для скриптов нет, они могут напрямую вызывать методы ядра или использовать любые классы, которые разрешены в trackstudio.properties. Еще интересная фича - при работе скриптов проверяются все permissions, поэтому если у пользователя есть права на просмотр handler-а для этой задачи, то task.getHandler вернет что надо, если нет, то вернет null.

примеры использования:

1) Вычисление значений custom-полей. При этом скрипт может генерить кусок html-страницы и можно делать экзотику, например, custom-поле в котором собраны ссылки на все аттачи. Его можно использовать чтоб загружать аттачи прямо со списка задач (страница subtasks):
http://www.trackstudio.com/documentation/3...ield_Value.html

2) Заполнение списка возможных значений для списочных custom-полей.

3) Триггера (аналог BEFORE/AFTER/INSTEAD OF триггеров в СУБД):
http://www.trackstudio.com/documentation/3...g_Triggers.html

4) CSV Import. В TrackStudio для импорта используется не wizard, а скрипт. CSV файл обрабатывается построчно, для каждой строки вызывается скрипт и он может создать необходимые объекты. Способ выглядит более сложным чем jira-шный wizard, но на порядок более гибкий: можно импортировать пользователей, задачи с сообщениями, можно на ходу создавать недостающие объекты, выстраивать импортируемые задачи иерархически и т.п.:
http://www.trackstudio.com/documentation/3...m_CSV_File.html

 

maximkr, 
Спасибо за исчерпывающий ответ! 

Вопрос по поводу Trac'а: хочу включить исходный код wiki в SVN-репозитарий проекта. Возможно такое?