Интеграция SVN с программным обеспечением для отслеживания ошибок - PullRequest
Новая
       25

Интеграция SVN с программным обеспечением для отслеживания ошибок

4 голосов
/ 04 января 2011

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

Например:

  1. Каждый разработчик имеет доступ только для чтения к SVN - он может обновлять источники, но не может фиксировать.
  2. Каждый коммит должен содержать идентификатор ошибки / тикета
  3. Даже для задач оптимизации разработчик должен создать заявку для себя, а затем реализовать некоторые вещи

Я знаю, что есть некоторые инструменты, такие как Mylyn, которые помогают интегрировать тикет-систему / SVN, но разработчик всегда может зафиксировать источники.

У меня нет каких-либо сред для системы тикетов (я могу использовать Trac так же, как BugZilla или любой другой), но я должен использовать SVN в качестве хранилища кода.

У вас есть идеи, как интегрировать эти услуги таким образом?

Ответы [ 3 ]

3 голосов
/ 04 января 2011

Для этого вида политики вы должны написать Hook Script, который проверяет, есть ли идентификатор билета в сообщении журнала и, конечно, проверяет, принадлежит ли идентификатор билета соответствующему проекту.Кроме того, вы можете использовать такие вещи, как Redmine в качестве системы тикетов.

3 голосов
/ 04 января 2011

Я недавно использовал TFS. У него есть возможность настроить аналогичный рабочий процесс - вы должны создавать «рабочие элементы», к которым вы можете прикреплять ошибки, в которые вы можете вносить изменения. Невозможно выполнить коммит без предварительного создания ошибки, без предварительного создания рабочего элемента.

Это привело меня в бешенство, и я изменил настройки, потому что мой рабочий процесс пошел так:

  • Счастливо редактируем код для исправления ошибки.
  • Найдите еще одну, не связанную ошибку.
  • Передать изменения кода в первую ошибку.
  • Остановить поток и запустить редактор рабочих элементов.
  • Выясните ужасный пользовательский интерфейс рабочего элемента VS2010 и создайте новый рабочий элемент.
  • Изучите ужасный баг-трекер VS2010 и создайте новую ошибку.
  • Вернуться к коду.
  • Определите, где была вторая ошибка.
  • Исправлена ​​вторая ошибка.
  • Вернуться к работе над исходной ошибкой.

На самом деле, мой рабочий процесс выглядит примерно так:

  • Счастливо редактировать код для исправления ошибки.
  • Найдите еще одну, не связанную ошибку.
  • Подумайте про себя: «Исправление этой строки кода займет у меня хороший час, чтобы возиться с тупыми баг-трекерами. Винт.»
  • Продолжайте работать над оригинальной ошибкой.

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

0 голосов
/ 04 января 2011

Если вы действительно хотите, вы можете взглянуть на gurtle, плагин для черепахи , который позволяет пользователям выводить список багз. Следуя этому шаблону, вы можете предложить способ быстро и легко создать дело / проблему, если ее нет.

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

...