2010-09-20

Личный опыт внедрения Redmine

Добрейшего.

Не так давно задумал совершить ряд движений и поменять СМ-процесс в своём проекте и, если получится, на проекте соседнем. Поводом было то, что меня перестал устраивать текущий инструмент отслеживания запросов на изменения. Начав думать над одним, огляделся и понял, что пора бы и всё остальное поменять, до чего давно не доходили руки.

В общем, перво-наперво задача стояла поменять систему отслеживания запросов на изменения, или попросту багтрекер. К моменту написания заметки на пробу использовал Jira, подумывал оценить её и предложить соседней команде в качестве альтернативы использовавшегося ими Eventum. Когда стали обсуждать переход в участниками команды, решили посмотреть на прайс Джиры... посмотрели и решили, что Redmine, обладающий тем же функционалом, но за бесплатно, вполне подойдет :) У меня был опыт его настройки и внедрения в процесс, так что переход обещал быть быстрым.



Настройка

Установили в локальную сеть на машину под управлением CentOS. Человек, непосредственно ставивший его, пользовался вот этой инструкцией по установке. Всё заработало сразу. (Есть ещё вот такая заметка про установку Redmine на CentOS + ISPManager, может быть, кому-то пригодится.)

Дальше мне пришлось немного поколдовать, чтобы привести настройки системы в соответствие процессу разработки.

Первым делом сменил заголовок. Был Redmine, стал Красношахтинск! Зато нескучно :) Правда, потом пришел директор и поменял обратно ;) А заодно сделал перевод на русский перечислимых терминов, например группы пользователей, состояния в workflow и список приоритетов (будет ниже).

Перво-наперво завел проекты, соответствующие рабочим задачам. К примеру, проекты, над которыми работаю я, разбиваются естественным образом по доменникам, на которым проекты крутятся. Поддомены - это, в свою очередь, подпроекты. Ну и в ним - своё разделение. У меня получилось 3 уровня вложенности.

А если задача к разным проектам? А в этом случае задача заводится в над-проекте. Например, есть www.project.ku и у него foo.project.ku и bar.project.ku. Задачи, общие для поддоменов, заводятся в www.project.ku.
Вот в соседней Команде Д (см. предыдущий пост) проект один, разбиение на проекты было сделано по а) разделам сайта б) крупным фичам, затрагивающим несколько разделов или сайт целиком.
В общем, способы нарезки предметной области у нас разные. Что лучше - посмотрим со временем, пока что всё устраивает.

Зачем вообще разбивать на проекты? Да хотя бы чтобы задачи не пересекались.в общем списке. Иногда это мешает, но в целом отторжения не вызывает.

Дальше определились с пользователями. Тут просто - завели на каждого участника проекта по юзеру, даже без привязки к Active Directory. Роли (roles) оставили те же, что и были по умолчанию и добавили новую, ну и директор их перевел на русский:
  • Менеджер
  • Разработчик
  • Репортер
  • Контент-менеджер
Группы пользователей (groups) фактически повторили роли - их стало 4 на каждую команду.

Следующая серия допиливаний пришлась на workflow. Трекеры (trackers) оставили почти как есть, с той разницей, что их переименовали. Было
  • Bug
  • New task
  • Support
Стало
  • Ошибка
  • Надо сделать
  • Разное
Что вполне соответствует их назначению в команде.

Приоритеты (priority) также были переименованы во избежание разночтений:
  • На потом (эту я добавил)
  • Низкий
  • Обычный
  • Высокий
  • Срочно!
  • Незамедлительно!!!
Дальше я решил немного доработать workflow, созданный по умолчанию. В первую очередь, состояния были переименованы:
  • Новая
  • Выполняется
  • Решена
  • Ожидает проверки
  • Закрыта
  • Отклонена

Закрыта и Отклонена - это финальные состояния, перевод в них закрывает задачу. Убрал из переходов состояние "Ожидает проверки" (Feedback). В принятом процессе оно было лишнее. Текущий процесс приведен ниже под пунктом "Использование"

Что ещё оставалось сделать - связать репозиторий SVN с Redmine.
Тут ждала неожиданность: если несколько проектов используют один репозиторий, то к каждому проекту его надо подцеплять отдельно! Учитывая, что репо у "Команды Д" Рэдмайн пережевывал минут 5 (и, соответственно, отъедал место на сервере под свою базу), подцепить репо к каждому из десятка проектов - это тот ещё геморрой... Увы, поиск по манам и форумам ничего не дал - пришлось подцеплять репо к проектам постепенно, по мере необходимости.

Отдельно надо сказать про связь записей Redmine и ревизий SVN. У Рэдмайн есть отличная фича - связывание ревизий в системе контроля версий и своих записей в базе. Т.е. если Василий Пупкин пофиксил в SVN ревизии 9874  баги #125 и #145, то в этих записях появятся ссылки на эту самую ревизию с указанием комментария из ревизии. Соответственно, можно пойти по ссылке и посмотреть внесенную дельту.
Для того, чтобы эта схема работала, надо чтобы в комментарии к ревизии было ключевое слово и номер записи, например "Just made minor fix #124.", где fix - ключевое слово, а #124 - это привязка к записи. Списко ключевых слов редактируется вот тут:

http://local_redmine/settings/edit?tab=repositories
секция Referencing keywords. Я добавил ключевые слова "fix,##,пофиксил,фикс".
Кстати, там же есть возможность привязывать ревизии к определенным состояниям записей - вообще чума! Жаль, нигде не пригодилось :)

Ну и ещё мелочь - о новых ревизиях Рэдмайн узнает (и связывает с задачами) только в 2 случаях:
  1. Когда кто-то заходит во вкладку "Хранилище" (Repository) или
  2. По запуску спецскрипта (например, по крону).
Об этом надо помнить и что-нибудь с этим сделать сразу после первичной настройки системы.

Из первичной настройки - вроде всё.

Использование

Текущий процесс работы над задачей выглядит примерно так.
  1. Запись заводится в состоянии Новая.
  2. Назначается на разработчика.
  3. Когда начинается работа, разработчик переводит в "Выполняется".
  4. Выполнена - он переводит её в "Решена".
  5. Менеджер, видя статус или услышав об изменении от разработчика - в одном комнате ведь сидим ;) - проверяет решение и переводит в "Закрыто".
  6. Или же обратно в одно из предыдущих состояний.
  7. Если заведенная запись не будет решаться по каким-то причинам - она двигается менеджеров в "Отклонена".
Права выставлены по следующим принципам:
  1. Менеджер может всё и ему разрешено движение между любыми состояниями.
  2. Разработчик может двигать запись только между соседними состояниями. Например, из "Выполняется" - только "Новая" и "Решена" или из "Новая" в "Выполняется". Закрыть задачу (перевести в "Закрыта" или "Отклонена") разработчик не может, иначе задача пропадет из поля зрения менеджера. Вместо этого он переводит её в "Решена" с соответствующим комментом.
  3. Репортер (по сути, тестер или сторонний наблюдатель) имеет право только на заведение записи.
Просто и всем понятно. Процесс в проектах несложный, поэтому и трекеры настроены соответствующим образом.

Кроме того, сразу была задействована встроенная Вики. Туда сейчас постепенно переносим нужную информацию.

Напоследок о фильтрах записей. Поскольку их (записей) было сразу заведено под сотню, понадобилось это всё как-то фильтровать. Помогли фильтры. Настроили пару-тройку public фильтров, чтобы все могли пользоваться.
  • "Все открытые, сгруппированные по состояниям", с сортировкой по приоритету - этот зрительно дает посмотреть что в работе, что закончено и что из очереди новых задач более приоритетное. Кроме того, тут же позывается столбец "Проект", чтобы видеть, откуда задача прилетела.
  • Разработчики настроили себе "Мои выполняющиеся" - туда попадают все, что в состояниях до "Решено". Мол, пусть решенные мозолят глаза менеджерам :)
  • "Все решенные незакрытые" - это для менеджеров, видеть что уже сделано.
Фильтры настраиваются очень просто, так что вполне может быть, что-то появится ещё.

Из повседневного - пока что всё. Посмотрим, что будет дальше.

P.S. Кому как, а у меня Redmine уже ассоциируется больше с системой управления проектами, чем с простым багтрекером.

Updates. Может также пригодиться инструкция по установке RedMine на Windows. Кому лень настраивать руками - есть отличная замена - Bitnami Stack.
Ну и вообще - почитайте до кучи обсуждение заметки на RSDN, есть полезные посты.

Как Redmine используется сейчас. И по многочисленным запросам - как закрыть задачу в Redmine.

А кому не хочется Редмайн - можете попробовать eTraxis. Очень рекомендую.

23 комментария:

  1. По поводу узнавания о новых ревизиях

    >По запуску спецскрипта (например, по крону).

    Можно подробнее? Можно конечно и самому поискать, но может другим читателям статьи тоже полезно будет.

    И сразу вопрос - оно будет весь репозиторий полностью перечитывать?

    И еще меня напрягает, что если я например поменяю log message у коммита, то редмайн об этом не узнает и в репозитории показывает старое log message. Мне пока приходится вручную удалять и передобавлять репозиторий в настройках редмайн. Можно ли как-то проще?

    ОтветитьУдалить
  2. Год назад ставил и настраивал на работе связку Redmine+SVN+AD. Поделюсь насчет новых ревизий.

    Когда в redmine добавляется реп, redmine сканирует комменты всех уже существующих коммитов и добавляет инфу о них к себе в БД. В дальнейшем, каждый раз когда кто-нить из юзеров открывает реп из веб-морды redmine, тот снова сканирует реп, но на этот раз только все те коммиты, которые он еще не сканировал (обновляя инфу в БД, разумеется). Таким образом скан коммитов происходит какбы автоматически и инкрементно.

    Однако действительно есть проблема с тем, что изменение комментария уже отсканированного коммита redmine не видит. Это я обошел следующим образом. У redmine есть скрипт, который делает примерно тоже самое - сканирует коммиты всех прикрученных к redmine репов. Но его можно запускать в двух режимах - инкрементный (как выше), или "с нуля". В последнем случае скрипт удаляет из БД redmine'а инфу обо всех уже просканированных коммитах, и пересканирует все по-новой. Однако операция эта разумеется длительная - у нас в репах были проекты "средней" тяжести (в плане кол-ва исходников, модулей, и прочего) и полный рефреш занимал больше двух часов. Поэтому я просто заскедулил этот скрипт, чтобы он запускался раз в сутки по ночам.

    Сам скрипт не скажу, под рукой redmine'а нет, да и многое поменяться могло за год (я тогда возился с версией 0.8). Инфу о скрипте я нашел в redmine'овых вики. Найдете и вы. ;)

    ОтветитьУдалить
  3. Что ж вы такое пишете, что рефреш репозитория идет 2 часа?
    У меня проект небольшой конечно, где-то 50-100К строк, пара тысяч коммитов, но рефреш репозитория происходит за минуту.
    Что должно быть в репозитории, чтобы рефреш происходил 2 часа?

    ОтветитьУдалить
  4. Код в основном пишем. :) Если подробнее, то реп содержал кодовую базу различных проектов, тем или иным образом посвященных видеоаналитике. В итоге в репозитории лежит:

    1. Код некоторых сторонних библиотек, например OpenCV или Protocol Buffers. Библиотеки OpenSource, так что мы их под себя бывает подтачиваем (с сохранением GPL-лицензии, разумеется ;) ), а потому готовые бинарники библиотек для нас не выход. В результате код лежит в репе и компиляется наравне с нашим собственным.

    2. Наш код также разбит на независимые библиотеки, посвященные тем или иным аспектам видеоаналитики. Например, модуль управления различными камерами, модуль распознавания лиц, модуль анализа пола (ака sex), и т.д.

    3. Разношерстные проекты, построенные на базе кода из первых двух пунктов, как из кирпичей.

    Ну и помимо этого репозитария, была еще пара - из соседних отделов. Не будем же мы ставить в каждый отдел по редмайну. :)

    Но вообще цифра действительно большая. Тут вот автор в личке пишет, что у них 7 тыс. коммитов сканилось минут 10, в то время как в "моем" репе на тот момент было около 8 тыс (т.е. немногим больше). SVN и Redmine жили на одном сервере, общались по протоколу "file://", так что сеть тут не причем. Насколько я понимаю, Redmine использует "svn log" для каждого коммита. Быть может, все дело в огромном кол-ве мелких файлов? По идее, размер файлов не должен играть роли, но если файлов количественно несколько тысяч, и во многих коммитах они участвуют сотнями...

    Ах да! У нас очень интенсивно использовались "бранчи", точнее то, что svn считает бранчами. И если кто-нить желал отрастить бранч от транка, он получал коммит, содержащий все несколько тысяч файлов. И таких бранчей в свою очередь сотни. Может, все дело в этом?..

    В общем, к концу ответа на ваш вопрос расписываюсь в собственном недоумении. Но факт остается фактом - лично замерял.

    ОтветитьУдалить
  5. Задачу обновления log message можно решить ручками из консоли ruby. Запускаем консоль командой ruby script/console production и выполняем следующий код:
    c = Changeset.find_by_revision(номер_ревизии)
    2 c.comment = "новый текст коммит-лога"
    3 c.save()
    4 c.scan_comment_for_issue_ids

    По поводу спецскрипта - он у меня запускается из post-commit хука, и выглядит вот так:
    ruby e:/redmine/script/runner "Repository.fetch_changesets" -e production
    Правда есть один минус - время коммита увеличилось секунд на 10.

    ОтветитьУдалить
  6. "Правда есть один минус - время коммита увеличилось секунд на 10."

    Не плохой такой минус :)

    Пока что сделали так:

    По крону:
    */5 * * * * rake -f /path/to/redmine/Rakefile redmine:fetch_changesets

    5 минут, кажется, не много и не мало.
    "-e production" не указывал - просто прописал в настройках database.yml для development всё то же, что и для production - для нас это не критично.

    ОтветитьУдалить
  7. Ну, нормально получается, 5 минут - в самый раз.

    ОтветитьУдалить
  8. Добрый день. Я пользуюсь bitnami. При попытке rake -f /path/to/redmine/Rakefile redmine:fetch_changesets оно выдаёт Access denied for user 'bitnami'@'localhost' to database 'redmine_development' =(

    ОтветитьУдалить
  9. Увы, Bitnami ставил в последний раз пару лет назад, не помогу...

    ОтветитьУдалить
  10. > Access denied for user 'bitnami'@'localhost' to database 'redmine_development'

    Судя по сообщению он пытается работать с development окружением. Попробуйте добавить:
    -e production

    ОтветитьУдалить
  11. Здравствуйте!
    Может кто-нибудь из активных юзеров redmine, сможет помочь:
    у нас редмайн не умеет ходить по свновским линкам(ссылкам).
    Линки из одного места свн в другое.
    Как это поправить??

    ОтветитьУдалить
  12. Что значит "из одного места свн в другое"? Ссылки - которые добавлены под контроль версий из файловой системы? Или ссылки на ревизии из тикетов?

    ОтветитьУдалить
  13. вообще, конечно, интересуют оба варианта.
    но начать можно с файловой системы.
    заранее спасибо!

    ОтветитьУдалить
  14. Ну про ссылки на ревизии - см. в статье.

    А насчет линков в ФС - тут уж не знаю. Задай вопрос на их форумах :)

    ОтветитьУдалить
  15. Здравствуйте! Кто-нибудь может подсказать, возможно ли при создании задачи сразу определить состав ее участников. Например есть перечень состояний:
    - В разработке
    - На проверке
    - Документируется
    хочется для каждого состояния определить исполнителя, т.е. указать Разработчика, Тестировщика и Писателя.

    ОтветитьУдалить
  16. Стандартными средствами такого не сделать. Поищи в плагинах - там должны быть такие, которые модифицируют стандартный workflow.

    ОтветитьУдалить
  17. 4to takoe sovmestnoe ispol'zovanie? naprimer, v sprintah est' takoe..hotelos' by uznat', 4to ozna4aet kajdyi iz nih

    ОтветитьУдалить
    Ответы
    1. А вы в контексте чего интересуетесь? Совместное использование Редмйна? Не совсем понял вопрос.

      Удалить
  18. Спасибо за статью, оказалась очень полезной. Надеюсь, что наш RMClient окажется полезен для тех, кто планирует проекты с помощью Redmine. Мы разработали таймер для учета времени в системе Redmine, он доступен для скачивания после короткой регистрации. Будем очень признательны за его использование и помощь в тестировании.

    ОтветитьУдалить
  19. сделал видео о интеграции Redmine с Rails Workflow - может быть кому-то будет полезно http://youtu.be/EexRvihtOMo

    ОтветитьУдалить
  20. Добрый день, коллеги. У нас Redmine на SQL. Можно ли где-то найти описание структуры базы. Так же есть потребность получения отчетов - можно ли их формировать в самом Redminе или как-то еще. Если можете помочь, пожалуйста напишите на info@altrim.ru

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.