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

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

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

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

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

EDIT2: поток о рабочем процессе Redmine/git: кажется, что самая типичная установка - то, что работы Redmine с локальным клоном того, что считается "центральным" репозиторием, таким образом, это видит изменения, когда они добираются до этого клона. Триггеры или запланированные задания автоматизируют продвижение к клону Redmine.

EDIT3: Кажется даже с Linux и Linus, в конечном счете СУЩЕСТВУЕТ основной репозиторий мерзавца, который можно было считать доброжелательным репозиторием диктатора: См. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary

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

15
задан RamC 26 August 2019 в 11:37
поделиться

6 ответов

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

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

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

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

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

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

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

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

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

END OF @Squelch

8
ответ дан 1 December 2019 в 03:14
поделиться

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

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

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

$ git log

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

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

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

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

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

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

5
ответ дан 1 December 2019 в 03:14
поделиться

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

1
ответ дан 1 December 2019 в 03:14
поделиться

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

0
ответ дан 1 December 2019 в 03:14
поделиться

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

0
ответ дан 1 December 2019 в 03:14
поделиться

Great Question.
For answering it, you need to look at what both of those tools (BugTracker.NET, which you know well, obviously ;) and Git, made initially for Linux in 2005) are actually trying to solve.

  • BugTracker.NET: web-based tracker, for bug (or pretty much any other "item" you want to track, since you can define your custom fields, status and workflow)
  • Git: at its core, it is a patch integrator, made to apply lots of patches from lots of people (not all of them known or with specific roles) to a large number of files. Quickly.

So you can see the dissonance here, between a central referential and a distributed code aggregation tool.

The lowest common denominator between those two model remain the "Benevolent dictator workflow", which is the most distributed workflow out there which still have a central repository for you to monitor.

But should you follow that path (monitor one repository acting as the "official referential", while having a loose distributed merge workflow below that one repo), you then need to re-define what is a user and its role.
Especially when it comes to integrate Git with your centralized role-based bug tracking tool.

If you watch Linus's presentation of Git at Google, around 18'35, you will get to the passage where you realize using Git means not having all the users identified and attached to a role.

Here is a couple of quick quotes/points that illustrate that fact:

  • “ Because you have a central repository means everybody who is working on that project needs to write to the central repository.
    Which means that, since you don't want everybody to write to the central repository, because most people are morons, you create this class of people who are ostensibly not morons. ”

So, not everyone will end up pushing to the central repository, and most of the actual work there (small fixes, validations, testing, ...) will be done by a limited number of people anyway.

That "Benevolent dictator workflow" means you works with a "network of trust": a selected group of people. Again, not all the developers are directly visible.

  • From the same presentation, what you also realize is that a "all repository" can be part of the lifecycle of the code (as opposed to branches 'integration', 'testing', 'to be released', or labels 'release1.0', ...):

“ One of the things for commercial companies: the distributed model also helps with the release process.
У вас может быть группа проверки, у которой есть собственное дерево. И они берут у людей, и они проверяют это, и они подтверждают это, они могут передать это команде выпуска и сказать: «Эй. Мы уже проверили нашу версию, и люди, занимающиеся разработкой, могут пойти вместо того, чтобы создавать ярлыки, ветки, что бы вы ни делали, чтобы держаться подальше друг от друга.
Опять же, вы держитесь подальше друг от друга, потому что каждая группа может иметь собственное дерево и отслеживать ее работу и то, что они хотят сделать.

Это подтверждает предыдущий пункт: если вы отслеживаете только одно репо, вы можете отслеживать коммиты только от ограниченного числа людей.
И это добавляет поворот:
While you cannot monitor all the repos out there, you may not want to monitor only one repo: if the bug tracking overlap several phases (namely 'contrinous integration', 'functional testing', 'user validation', 'pre-production', ...), each of them potentially having their own tree, and each of them being a potential source for filling a bug report.
In that respect, the "Git branch support by Redmine" (Revision 2840) is still made with a "centralized repo" mindset, where you use a branch for a development lifecycle modelisation (where you do tasks about and around development, instead of doing an actual "development effort" which is what a branch should be all about).


Where does all that leave you?

  • either imposing a strict central repository model (everybody must push to one repo), which, in my experience, is never good when a tool try to force you to work one way instead of letting you adapt the tool to the way you want to work.

  • or redefining the bug lifecycle management to take into account:

    • potentially multiple trees, each one a potential step in a bug resolution.
    • users that will be registered as working on a bug, but with no complete code history: i.e. the code monitored might not be directly associated with them, since the resolution can be done in private branches on developer's repositories, while the monitored code is made from multiple merges by one 'integrator' on dedicated repositories.
    • intelligent reporting able to tell what bugs are detected/fixed in an "official revision" of the code, limiting themselves to point out the origin of those changes (it comes from the merges of such remote branches, for such remote repo)

In short, this is not a trivial task.

The issues remain:

  • Git publication workflow, which is inter-repo (push/pull) as well as intra-repo (merge/rebase): which ones do you want to track?
  • Git private branching: not all the history of the code will ever be visible, and should not be tracked. Only public branches (which are pulled/pushed, but also modified within their own repo by some merge or rebase) should be tracked
  • Git users: according to their place within the "network of trust", they have different roles that the tracker needs to reflect.
8
ответ дан 1 December 2019 в 03:14
поделиться
Другие вопросы по тегам:

Похожие вопросы: