Связывание коммитов с проблемами - лучшие практики

Мы пытаемся внедрить то, что, как мы надеемся, является хорошей практикой разработки: каждая фиксация должна быть связана с проблемой в системе отслеживания ошибок. (Совершенно приемлемо создать новый выпуск, чтобы удовлетворить это требование.)

Наш трекер проблем (Redmine) и DVCS (Mercurial) хорошо интегрируются, но у нас есть одна проблема: что произойдет, если разработчику нужно что-то зафиксировать в автономном режиме? В настоящее время доступ к Redmine осуществляется онлайн, а доступ к Mercurial осуществляется через TortoiseHG (Windows) или оболочку (Linux).

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

Что нам делать? Я вижу следующие варианты:

  1. Переключитесь с Redmine на средство отслеживания проблем с автономной поддержкой. [Я не думаю, что Trac намного лучше]

  2. Придумайте какое-нибудь решение для создания проблем в Redmine в автономном режиме. [не знаю как, не вызывая, а не решая проблем]

  3. Откажитесь от идеи, что коммиты всегда должны относиться к существующей проблеме. [но это казалось такой хорошей идеей]

  4. Обратная ссылка фиксирует проблемы. [это требует, чтобы разработчики записывали описание каждой проблемы во временном месте, позже копировали их в Redmine, а затем вручную связывали новую проблему с фиксацией; неэффективен и подвержен ошибкам]

  5. Запретить офлайн-коммиты (таким образом, запретить работу офлайн). [кажется глупым, учитывая, что DVCS был выбран в первую очередь для работы в автономном режиме]

Что бы вы посоветовали?


version-control project-management redmine dvcs mercurial
person max    schedule 17.08.2012    source источник
comment
Вы говорите здесь о рабочем процессе, когда разработчик обнаруживает ошибку в автономном режиме? Диагностирует и устраняет проблему в автономном режиме, а затем хочет зафиксировать исправление (в автономном режиме)? Это похоже на то, что разработка управляет системой отслеживания проблем, а не наоборот? Как насчет того места, где текущие проблемы становятся приоритетными?   -  person Nick Pierpoint    schedule 24.08.2012
comment
@NickPierpoint: мы пытаемся перейти к разработке системы отслеживания проблем , когда это возможно, но ваш пример все еще встречается довольно часто - например, когда я путешествую. Конечно, я не буду знать о последних изменениях приоритетов; по-видимому, кто-то из сотрудников офиса может их решить, а я, по крайней мере, могу сделать что-нибудь полезное для старых вопросов. Кажется ли такое расположение разумным?   -  person max    schedule 24.08.2012
comment
Значит, во время путешествия у вас нет доступа к Интернету? Нет возможности связаться с офисом для создания проблемы? Трудно поверить, что вы потеряете связь в течение длительного периода - если это так, то совершайте локальные транзакции без связи с внешним миром, а затем следуйте совету Рагурама, когда вы вернетесь на поверхность.   -  person Nick Pierpoint    schedule 29.08.2012

Ответы (3)


arrow_upward
1
arrow_downward

Одно дело работать над проблемами в автономном режиме и фиксировать локально, а другое - продвигать их вверх по течению (скажем, на назначенный сервер).

Первое можно сделать без доступа к Redmine. Либо существующая проблема с Redmine может быть, либо необходимо создать новую проблему и связать ее с коммитами.

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

person Raghuram    schedule 17.08.2012
comment
Очень интересно, я не знал, что могу редактировать коммиты или сворачивать их. Думаю, это почти идентично варианту 4. Единственная разница в том, что вместо того, чтобы задним числом связывать проблемы с коммитами, мы задним числом редактируем коммиты. К сожалению, нам по-прежнему необходимо временно хранить информацию о том, что делала каждая фиксация, а затем копировать / вставлять ее в сообщения redmine и commit. - person max; 17.08.2012

arrow_upward
0
arrow_downward

Здесь у меня есть коммиты, связанные с конкретными проблемами (в случае фиксации ошибок). Система проста:

  1. В сообщении о фиксации вы вводите номер ошибки в квадратных скобках.
  2. Когда мы делаем релиз, мы собираем все коммиты, сделанные с момента последнего релиза.
  3. С помощью регулярных выражений мы извлекаем идентификаторы исправленных ошибок.
  4. Мы используем этот список для обновления базы данных ошибок и создания журнала изменений.

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

Изменить: Относительно части "работа в автономном режиме". Mercurial - это DVCS, и он не предназначен для постоянного подключения. Примите это, разрешите локальные коммиты и обработайте базу данных ошибок, когда вы вернетесь в сеть и / или нажмете кнопку.

person Mizipzor    schedule 17.08.2012
comment
Но как узнать, что писать в квадратных скобках, если у вас нет доступа к базе данных ошибок? А что, если ошибки еще нет в базе данных, когда вы ее обнаружили (в автономном режиме)? - person max; 17.08.2012
comment
@max с mercurial - это легко редактируемая (неопубликованная) история. У всех в команде своя стратегия. Лично я обычно просто использую заполнитель, например [XXXX], пока не вернусь в сеть и не проверил номер в базе данных об ошибках (или не сообщу об ошибке, чтобы получить его). - person Mizipzor; 20.08.2012

arrow_upward
0
arrow_downward

Redmine фактически имеет автономную возможность создавать проблемы: его можно настроить для приема новых проблем и выпуска обновлений по электронной почте. И большинство почтовых клиентов работают в автономном режиме (временно сохраняя сообщение в папке «Исходящие», пока пользователь не выйдет в онлайн).

Электронная почта также может обеспечивать (очень ограниченный) автономный режим просмотра. Если я буду получать уведомления по электронной почте о каждой новой проблеме и обновлении и автоматически перемещать эти электронные письма в отдельную папку, я могу найти соответствующий номер проблемы.

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

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

person max    schedule 19.08.2012