Процесс разработки программного обеспечения со временем обрастает множеством вспомогательных инструментов. Не только теми, которые помогают лучше писать, компилировать или тестировать код, но и теми, чьё единственное предназначение — упорядочивать рабочий процесс. Вот, практически, минимальный набор для небольшого проекта: система контроля версий, багтреккинговая система, wiki. Действительно ли это нужно вашему проекту?
Зачем это нужно?
Могу вывести несколько эмпирических закономерностей появления потребности в определённых инструментах:
- Система контроля версий нужна даже для соло-проектов. Очень важна возможность не думать о ведении истории и о резервном копировании старых версий. Настолько важна, что глупо от неё отказываться для любого проекта, длиннее пары дней, результаты которого могут вам понадобиться больше одного раза.
- Пока разработчик один, обсуждать найденные ошибки можно и по электронной почте. Как только в проекте появляется два разработчика, вам становится нужен багтреккинг: как решение проблемы единого хранилища информации об ошибках. Эти же соображения относятся к планам работ, которые лучше всего вести в той же багтреккинговой системе. Туда же должны попадать все «заявки» от заказчиков: как сообщения об ошибках и неудобствах, так и запросы на добавление нового функционала.
- Когда проекту становится нужна wiki? Как только написанием и редактированием документации начинает заниматься более одного человека. Я считаю, что в идеале написанием и редактированием документации должны хоть немного заниматься все разработчики. В противном случае страдает как качество и полнота документации, так и качество и полнота осмысления проекта его участниками. Первое — ерудна, но от второго проект будет очень сильно страдать. Для аутсорсинга wiki обладает ещё одним преимуществом: чтобы документы читали, и программистам, и заказчикам нужна возможность сделать это легко и просто. Чтение через браузер вполне подходит. Скачивание отдельных doc-файлов с FTP — не очень. Если документация лежит на FTP, то, как показывает мой опыт, практически никто до этого FTP не добирается.
Таким образом, уже для небольшого проекта, включающего менеджера, двух разработчиков, бизнес-аналитика и тестировщика, весь перечисленный набор инструментов из прихоти превращается в необходимость.
Всё в одном
Есть замечательный инструмент, который обеспечит вас «базовым набором» для управления проектом. Я говорю о Trac. Это багтреккинговая система, wiki и тесная интеграция с Subversion в одном флаконе. Основная цель Trac в том, чтобы обеспечить проект основным инструментарием управления, как можно меньше путаясь при этом под ногами участников. Заявленная цель достигнута: Trac действительно объединяет в себе практически все необходимые функции инструмента управления проектом и одновременно по минимуму заставляет участников проекта заниматься ненужной работой. В других багтреккинговых системах, которыми я пользовался, рутинные и не очень нужные операции отнимают гораздо больше ценного человеческого времени.
Что мне понравилось в Trac
- Автоматическое закрытие бага при помещении исправления в source control. Если вы пользуетесь Subversion, то разработчику достаточно написать в комментарий «Fixes #89. Now database exceptions are handled properly» при очередном коммите — и баг номер 89 будет отмечен как fixed с соответствующим комментарием. Вот так выглядит такой баг в истории изменений:
- Wiki для всей документации. Огромный шаг вперёд по сравнению с набором несвязанных документов, разбросанных по FTP / файловому серверу. Вы получаете:
- Возможность с лёгкостью создавать ссылки между документами;
- Полную историю изменений любого документа;
- Беспроблемное совместное редактирование.
- Timeline. Функция Timeline позволяет получить единый отчёт о всех изменениях в коде, документации и багах. Позволяет постоянно «держать руку на пульсе» прогресса работ. Очень удобно не только для менеджера, но и для разработчиков, у которых по определению мало времени на отслеживание текущей ситуации.
- Интегрированный просмотр изменений. Любое изменение кода можно просмотреть в виде раскрашенного diff прямо в Trac. Эта возможность экономит много времени при ревью исправлений или изменений: не нужно смотреть в одном окне историю изменений, а в другом — искать эти изменения в логе Subversion и генерить diff; вместо этого достаточно просто открыть ссылку в Trac. Вот как это выглядит:
Что не понравилось
Долгая и сложная инсталляция. Trac требует для своей работы несколько сторонних компонентов, которые надо ставить отдельно. Инсталляция всего этого зоопарка на моём хостинге отняла у меня около 7 часов, заполненных попытками всё это правильно поставить. И это при наличии инструкции.
Впрочем, установка под root была бы заметно проще. Помимо инсталляции ядра, я потратил несколько часов на то, чтобы настроить автоматическое изменение багов по результатам коммитов в Subversion, и так ничего и не добился. Буду пробовать ещё, но доказательство сложности инсталляции налицо.
Автор: Александр Лебедев.
Комментарии:
Иван Сагалаев:
October 18th, 2006 at 02:26
Автоматическое закрытие бага при помещении исправления в source control. Если вы пользуетесь Subversion, то разработчику достаточно написать в комментарий “Fixes #89. Now database exceptions are handled properly” при очередном коммите – и баг номер 89 будет отмечен как fixed с соответствующим комментарием. Вот так выглядит такой баг в истории изменений:
По идее, это фича целиком Subversion. Там можно настроить вызов своих действий на каждый коммит, и в прицнипе, никто не мешает связать это практически с любой багтракинговой системой, которая работает по HTTP.
Но в заслугу Trac’у безусловно идет то, что это настроено :-)
Алексей:
October 24th, 2006 at 02:02
Я вот обнаружил, что для моего проекта Trac не очень подходит, а хотелось бы, т.к. интерфейс действительно удобный.
В Trac понятия “version” и “milestone” привязаны к проекту целиком. В моём же проекте есть тесно зависимые по документации, но сильно отличающиеся по срокам релиза/версиям части. Поэтому, хотя Trac и поддерживает несколько проектов на одном компьютере, и даже исходники никто не мешает хранить в одном репозитории, я не могу пользоваться Trac, т.к. документация и тикеты не могут быть общими на несколько проектов, а версию/дату релиза невозможно сделать разными для частей одного проекта.
grinka:
February 21st, 2007 at 12:05
Сильно не понравились сложности с русским языком. Любые комментарии и строки, попадающие в SVN на русском языке показываются не по-русски. Установка плагинов – тоже крайне неудобоваримый процесс.
woto:
May 7th, 2007 at 07:44
Не правда, поверхностный осмотр настроек навел на кодировку и благополучному решению всех проблем.
Alex Lebedev:
May 9th, 2007 at 01:51
Не правда, поверхностный осмотр настроек навел на кодировку и благополучному решению всех проблем.
Спасибо, мне тоже помогло. Сменил в trac.ini кодировку на utf-8: теперь русские комментарии отображаются корректно. Сейчас потребности в русских комментариях нет, но приятно быть готовым к ее появлению.
masterik:
July 27th, 2007 at 07:38
Для тех кому не хочется возится с установкой Trac (как мне например) есть уже готовые решения:
***
***
Игорь:
February 6th, 2008 at 06:14
А никто не пробовал искать русскоязычный интерфейс для трека? И вообще есть ли там поддержка многоязычности?
Alex Lebedev:
February 6th, 2008 at 06:25
Локализации интерфейса, насколько я знаю, нет.
Wiki и описания тикетов поддерживают русский язык. Как насчет показа изменений из Subversion с комментариями на русском — не знаю. Не знаю даже, поддерживает ли это сам Subversion.
Юревич Юрий:
February 12th, 2008 at 11:28
Как насчет показа изменений из Subversion с комментариями на русском — не знаю. Не знаю даже, поддерживает ли это сам Subversion.
Всё работает. И описание коммитов, и svn-postcommit хуки для работы с тикетами (refs, fixes).