Как интеграция отслеживания ошибок / контроля версий работает с типичными рабочими процессами git?

https://stackoverflow.com/questions/1484153

18-09-2019
|

Вопрос

Вот примеры рабочих процессов git:

Допустим, вы хотели воспользоваться преимуществами интеграции багтрекера с вашей системой контроля версий.Где / как это вписалось бы в эти рабочие процессы.Что бы вы на самом деле увидели в трекере?

Я автор BugTracker.NET, который, как и многие другие средства отслеживания ошибок (Trac, Redmine, FogBugz), интегрируется с svn.Мы все делаем это более или менее одинаково.Но с git мне трудно представить, как будет выглядеть интеграция с git.

Редактировать:Я взглянул на одну попытку гитхаб-fogbugz интеграция, но даже автор этого говорит: "Совершенно очевидно, что FogBugz был написан для более традиционной системы CVS / SVN SCM с учетом.Таким образом, отображение списка фиксаций на самом деле не совпадает с git ".

РЕДАКТИРОВАТЬ 2:Тема о Рабочий процесс Redmine / git:Похоже, что наиболее типичная настройка заключается в том, что Redmine работает с локальным клоном того, что считается "центральным" репозиторием, поэтому он видит изменения, когда они вносятся в этот клон.Триггеры или запланированные задания автоматизируют отправку в клон Redmine.

РЕДАКТИРОВАТЬ 3:Кажется, даже с linux и Linus, в конечном счете, существует основной репозиторий git, который можно считать репозиторием benevolent dictator:Видишь http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git ;a=краткое изложение

ЭПИЛОГ:Спасибо всем.Мой BugTracker.NET теперь включает интеграцию с git, в соответствии с рекомендациями, которые вы, ребята, мне дали.

Решение

Trac и Redmine поддерживают интеграцию с Git.Это выглядит более или менее точно так же, как поддержка Subversion.Отслеживание ошибок следует за одним репо в качестве великодушный диктатор repo, ему не обязательно заботиться обо всех других клонах по всему месту.

Одна вещь, которую, я думаю, стоит упомянуть, - это то, что любой багтрекер должен должным образом поддерживать ветви git.Работа с ветвями - настолько важная часть методологии Git, что ее необходимо поддерживать в багтрекере.Redmine может сделать это с помощью патча, но в последний раз, когда я смотрел (около месяца назад), его не было в основном дереве исходных текстов (вы могли следовать только за master).

Другими полезными функциями было бы графическое представление того, как создаются и объединяются ветви, аналогично тому, как выглядит gitk.Я не знаю ни одного багтрекера, который делал бы такого рода визуализацию.

РЕДАКТОР Кори Трэгер.Я скопировал / вставил ответ @Squelch здесь (я тоже поддержал @Squelch):

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

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

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

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

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

КОНЕЦ @Шумоподавления

Другие советы

Отличный вопрос.
Чтобы ответить на этот вопрос, вам нужно посмотреть, что представляют собой оба этих инструмента (BugTracker.NET, который вы, очевидно, хорошо знаете ;) и Мерзавец, изначально созданный для Linux в 2005 году) являются на самом деле пытаюсь решить.

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

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

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

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

Если вы наблюдаете Презентация Git Лайнуса в Google, примерно в 18'35 вы дойдете до отрывка, где поймете, что использование Git означает отсутствие ВСЕ пользователи, идентифицированные и привязанные к роли.

Вот пара кратких цитат / моментов, которые иллюстрируют этот факт:

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

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

Этот "Рабочий процесс доброжелательного диктатора" означает, что вы работаете с "сетью доверия".:избранная группа людей.Опять же, не все разработчики видны непосредственно.

Из той же презентации вы также понимаете, что "весь репозиторий" может быть частью жизненного цикла кода (в отличие от ветвей "интеграция", "тестирование", "подлежащий выпуску" или меток "release1.0", ...):

“ Одна из вещей для коммерческих компаний:распределенная модель также помогает в процессе выпуска.
У вас может быть команда проверки, у которой есть свое собственное дерево.И они извлекают информацию из людей, и они проверяют это, и они это проверили, они могут передать это команде по выпуску и сказать "Привет.Теперь мы убедились наш версия и разработчики, они могут продолжать играть своей головой, вместо того чтобы создавать теги, ветви, что бы вы ни делали, пытаясь держаться подальше друг от друга.
Опять же, вы держитесь подальше друг от друга, просто каждая отдельная группа может иметь свое собственное дерево и отслеживать свою работу и то, что они хотят сделать.”.

Это подкрепляет предыдущий тезис:если вы отслеживаете только одно репо, вы можете отслеживать коммиты только от ограниченного числа людей.
И это добавляет изюминку:
Пока вы не можете контролировать ВСЕ существующие репозитории, возможно, вы не захотите отслеживать только одно репозиторий:если отслеживание ошибок перекрывает несколько этапов (а именно "комплексная интеграция", "функциональное тестирование", "проверка пользователя", "предварительная подготовка", ...), каждый из них потенциально имеет свое собственное дерево, и каждый из них является потенциальным источником для заполнения отчета об ошибке.
В этом отношении "Поддержка ветки Git со стороны Redmine" (Редакция 2840) по-прежнему создается с учетом подхода "централизованного репо", когда вы используете ветку для моделирования жизненного цикла разработки (где вы выполняете задачи по поводу и вокруг разработка, вместо того чтобы предпринимать реальные "усилия по разработке", которыми и должна быть ветка).

Куда все это тебя ведет?

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

Короче говоря, это нетривиальная задача.

Проблемы остаются:

Рабочий процесс публикации Git, который является промежуточным (push / pull), а также внутрирепозиционным (слияние / перебазирование):какие из них вы хотите отслеживать?
Частное ветвление Git:не ВСЕ история кода всегда будет видна, и ее не следует отслеживать.Следует отслеживать только общедоступные ветви (которые извлекаются / выталкиваются, но также изменяются в пределах их собственного репозитория каким-либо слиянием или перебазированием)
Пользователи Git:в зависимости от их места в "сети доверия" у них разные роли, которые трекер должен отражать.

Чтобы повторить ответ Майклма, Redmine имеет хорошую интеграцию с Git.Он следует за сообщениями о фиксации для ключевых слов, таких как ссылки.исправления и т.д. и номер трекера формы #1234.

Это правда, что поддержка ветвей еще не совсем налажена, но она вошла в магистраль около месяца назад, и предназначен для версии 0.9.Redmine в настоящее время поддерживается в SVN, но есть также зеркало на Github

Ссылка на Redmine trunk указывает на выходные данные трекера для репозиториев Git с различиями в том, как осуществляется навигация по ветвям.

$ git log

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

Редактировать: Из-за распределенного характера Git в отличие от централизованного характера SVN, вполне возможно, что у каждого пользователя или копии репозитория будут разные ветви.Существующие трекеры обычно имеют локальную копию репозитория, которая используется в качестве центральной ссылки ("доброжелательный диктатор"), которую можно рассматривать как рабочую копию для всех пользователей.

Там также есть интеграция с открытым исходным кодом с помощью Fogbugz, на GitHub, конечно.

Взгляните на то, как Launchpad делает это:отслеживание состояния ошибки в разных местах.

Ниже я процитирую Марк Шаттлворт:

По-настоящему распределенное отслеживание ошибок (где список ошибок следует за кодом повсюду) - это очень интересно и может стать долгосрочным решением.В тем временем вы можете устранить проблему, просто отслеживая состояние ошибки в нескольких разных местах.Canonical финансирует работу над Bugzilla, Trac и другими средствами отслеживания ошибок, чтобы упростить общение с ними программно, чтобы мы могли обновлять разработчиков Ubuntu автоматически.

У нас есть "централизованное представление состояния распределенной ошибки" в Launchpad, которое помогает нам отслеживать статус проблемы выше по потоку, в Debian или в других дистрибутивах.Например, проверьте эти ошибки:

https://bugs .launchpad.net/moblin-applets/+bug/209870
https://bugs .launchpad.net/ubuntu/+source/nfs-utils/+bug/214041
https://bugs .launchpad.net/ubuntu/+source/tuxmath/+bug/220319
https://bugs .launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/123920
https://bugs .launchpad.net/ubuntu/+source/warsow/+bug/131582

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

Централизованное представление не является окончательным решением, но оно работает для нас прямо сейчас и довольно много других проектов - upstreams и distributions - тоже используют его.

Redmine уже интегрируется с Git, и это с открытым исходным кодом.Может быть, вы сможете взглянуть на их интеграцию в поисках идей.

Возможно, я немного наивен, но действительно ли отслеживание ошибок в git настолько отличается от svn?Репозиторий, используемый системой, в основном будет иметь ту же структуру (ветви и теги), что и в subversion, верно?

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow