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

Вариантов решения проблемы несколько.

1. Оставить все как есть, пусть разработчики сами решают как им быть дальше. Вариант самый простой, но про последствия писать, думаю, излишне.
2. Напрячь разработчиков – пусть пишут «самую лучшую в мире BTS в отдельно взятой конторе». Если клиенты могут подождать, и денег/времени не жалко – отличный вариант.
3. Использовать готовое решение и при необходимости доработать его под свои нужды. Вот на этом, пожалуй и остновимся.

Итак, перед нами стоит задача выбора системы отслеживания ошибок (bug tracking system, BTS) удовлетворяющую следующим базовым требованиям

• Поддержка большого количества проектов
• Удобный и функциональный web-интерфейс
• Наличие интеграции с системами контроля версий
• Поддержка многоязычности
• Учет и планирование рабочего времени
• Организация внутрикомандного взаимодействия разработчиков
• Работа с базами знаний (к примеру, wiki)
• Легкость доработки под нужды компании.
• Легкость установки и сопровождения.

В процессе поиска было найдено несколько десятков различных решений от самых разных производителей.

Закрытые проприетарные разработки мы отметаем сразу как минимум потому что что-либо поменять в них при не обходимости возможным не представлятся.

Open Source разработки представлены добрым десятком проектов. Рассмотрим самые популярные из них.

Итак, список кандидатов:

• Bugzilla
• Mantis Bug Tracker
• Trac
• Redmine

Начнем с Bugzilla. (http://www.bugzilla.org)

Проект достаточно взрослый, первый релиз вышел в 2001 году. Написан на perl. В дистрибутиве debian lenny присутствует, что довольно таки упрощает его установку.

Ставим, смотрим.

Картина, прямо скажем, не очень. Поддержки разных языков из коробки нет (хотя можно загрузить и поставить ручками). Интеграции хотябы с SVN – нет. Wiki отсутствует, как прикрутить – сходу не ясно. Управление правами пользователей довольно неочевидно. Пробуем создать новый проект, пару-тройку багов и понимаем, что до вменяемого вида его еще пилить и пилить.
Смотрим на полсотни перловых скриптов, открываем process_bug.cgi с 2200+ строк перлового кода и молча сносим bugzilla до лучших времен.

Следующий кандидат – Mantis Bug Tracker. (http://www.mantisbt.org)
Написан на php, в установке простой донельзя.

Первое что бросается в глаза – весьма унылый внешний вид. Понятно разработчики настолько суровы, что им в общем-то все равно, как интерфейс сверстан, но ведь есть еще и клиенты, которым иногда тоже нужно открывать баги, принимать участие в обсуждениях.. Идем дальше. Wiki нет, хотя судя по документации некая Docu Wiki к нему прикручивается, интеграциию с svn видимо тоже придется реализовывать кувалдой и сварочным аппаратом. Таймтрекинг присутствует в зачаточном состоянии в виде какого-то плугина. Особенно настораживают многочисленные отзывы о проблемах с unicode. Взглянув на исходники, мысль о переделке или дописыванию рассасывается как по волшебству – около мегабайта слабо струкурированного php кода без малейшего намека на mvc и на стройный api мало кого вдохновит на подобные подвиги. Вывод: лучше не надо.

Trac (http://trac.edgewall.org)

Написан на питоне. Поставился на первый взгляд без особых проблем, но дальшейшие разборки с отдельными модулями и apache преватились в довольно увлекательный квест. Вдоволь наматерившись я его таки поборол, но пожелать подобного развлечения могу разве что конкурентам (и то не всяким). Как впоследствии оказалось, я не один такой счастливчик – 161000 результатов в выдаче гугла по запросу ‘trac install problem’ мягко говоря настораживают.
В целом система довольно приятная, но есть ряд довольно серьезных «но».
Работа с несколькими проектами требует довольно нетривиальных телодвижений, в частности создания отдельного окружения для каждого нового проекта. Когда их 3-5 это еще терпимо, но если 30-50? а 150? Да и python как-то оптимизма не добавляет…
Вывод: проект интересный, перспективный, но не для нас. увы.

Redmine. (http://www.redmine.org)

Написан на Ruby on Rails. Установился влёт – читая документацию, на установку я затратил около 15 минут. Сразу порадовала поддержка целой кучи баз данных – начиная от sqlite и заканчивая postgres. Интерфейс – весьма приятный, кое-где используется ajax, формы читабельные и понятные. В общем – клиенту показать не стыдно. Кстати, из коробки присутствует поддержка около 30 языков (в том числе русский и украинский). Пристуствует встроенный движок wiki, форум, совместногое хранилище файлов. Интеграция из коробки с svn, cvs, git, mercurial и рядом других систем хранения версий. Гибкая и, главное, понятная система разграничения прав доступа пользователей, дополнительных полей в сообщениях об ошибках и проектах. Не найдя сходу к чему придраться, решил заглянуть в код чтобы забраковать по причине сложности доработки, и… Не получилось. Фреймворк RoR вполне оправдал ожидания – MVC во всей своей красе. Представление отделено от логини обработки, логика отделена от данных. Красота.

Погоняв систему в тестовом режиме месяц глюков замечено не было, за исключением проблем с падением mongrel (решено уходом на fastcgi за 10 минут)

Вывод: redmine – наш выбор несмотря на «всего лишь» 3 летний срок существования проекта. Система идеально подходит как и для текущей работы, так и в качестве «трамплина» для разработки своей системы отслеживания ошибок.

Метки: bug tracking, обзор