Выбор системы отслеживания ошибок
Для «Алтимы», как и для любой организации, занимающейся разработкой и поддержкой программных продуктов, проблема организации рабочего процесса стоит достаточно остро. Как правило, все начинается просто — с фиксации проблем и отслеживания процесса их решения, но с ростом клиентской базы этого становится недостаточно. Появляется необходимость в ведении общей «базы знаний» компании, учета рабочего времени сотрудников, организации командной работы и кучи всего остального.
Вариантов решения проблемы несколько.
- Оставить все как есть, пусть разработчики сами решают как им быть дальше. Вариант самый простой, но про последствия писать, думаю, излишне.
- Напрячь разработчиков — пусть пишут «самую лучшую в мире BTS в отдельно взятой конторе». Если клиенты могут подождать, и денег/времени не жалко — отличный вариант.
- Использовать готовое решение и при необходимости доработать его под свои нужды. Вот на этом, пожалуй и остновимся.
Итак, перед нами стоит задача выбора системы отслеживания ошибок (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, обзор















