Verteilte Problemverfolgung [geschlossen]

Das verteilte Issue-Tracking scheint mir eine Idee zu sein, hat sich aber nie wirklich durchgesetzt. Gibt es dafür einen guten Grund?

Ich bin mir bewusst, dass:

Bugz überall
- zu komplex zum Einrichten
- zu viele Anforderungen
- ziemlich erfolgreich, von einigen großen Projekten verwendet
Fossil
- versucht zu viele Dinge zu integrieren und ist am Ende eine etwas schlechtere Version von allen - außer vielleicht dem verteilten Teil der Problemverfolgung, der anständig ist (wahrscheinlich das Beste, was ich je gesehen habe)
mehrere andere kleinere Projekte
- Keiner von ihnen hat an Zugkraft gewonnen

Ich denke darüber nach, meine eigenen zu machen, aber bevor ich anfange, würde ich gerne wissen, warum keiner der anderen in großem Stil gestartet ist.

Erwartete Probleme: (Ich denke, sie können alle überwunden werden)

Das Zusammenführen verteilter Probleme beim Aktualisieren ist komplex, ebenso wie das Zusammenführen von Codedateien
Die Kontinuität der Konversation kann zerstört werden, da Kommentare jederzeit eingehen können, möglicherweise nicht im richtigen Ablauf
Erwartung eines zentralen Servers mit aktuellen Problemen

version-control issue-tracking distributed-computing Billy Moon
quelle

Mein 2c ist, dass verteiltes Issue-Tracking in vielerlei Hinsicht nicht viel Sinn macht - das Ziel des Issue-Tracking ist es, alle auf derselben Seite zu halten, so dass eine zentrale Zentralisierung gut ist. Wenn ich verteilt werden wollte, würde ich einfach evernote verwenden.

Wyatt Barnett

@ WyattBarnett, das ein berechtigtes Anliegen ist, möglicherweise durch Verhaltensmuster und möglicherweise Software gemildert. Persönlich sehe ich den einzigen Unterschied zwischen einem Blog und einer Website darin, wie oft Sie es aktualisieren. Ist es nicht dasselbe für die verteilte Problemverfolgung? Wenn Sie es häufig aktualisieren, ist es dasselbe wie das Überprüfen einer Webseite mit Problemen, oft nicht? Die einzige Gefahr besteht darin, dass Benutzer nicht aktualisieren und häufig Probleme einreichen. Solange es jedoch eine Ein-Klick-Lösung gibt, ist dies kein Problem, oder? Ich verstehe, dass dieses Bedürfnis nach Konnektivität im Widerspruch zu einem der großen Vorteile der distributedProblemverfolgung steht.

Billy Moon

Das Nichteinreichen von Problemen ist das Hauptproblem, das ich in Bug-Trackern gesehen habe. Wie @JeffO hervorhebt, sind einige Offline-Funktionen weitaus wichtiger als ein verteiltes System. Auf die gleiche Weise ist Git nett, aber Github macht Git wirklich lohnenswert.

Wyatt Barnett

@ WyattBarnett Es ist schwer zu spekulieren, wie Menschen auf ein gut geformtes Werkzeug reagieren würden. Vielleicht würden sie Probleme eher einreichen, wenn dies offline und ohne Verbindung / explizite Anmeldung möglich wäre. Vielleicht würden Personen, die Probleme online einreichen, ihre Beiträge verzögern, wenn sie offline verfügbar wären. Meine Intuition ist, dass Menschen es häufig tun, wenn es extrem einfach zu pushen ist, denn wenn sie ein Problem geschaffen haben, wollen sie, dass die Welt es sieht.

Billy Moon

Wie wird ein Manager zwei verschiedene Projekte mit einer Überlappung von Teammitgliedern behandeln? Sie wollen eine unternehmensweite Berichtsfunktion.

JeffO

Antworten:

Nur weil Source Control + Distributed ein großer Erfolg war, ist Issue Tracking + Distributed nicht unbedingt eine gute Idee.

Was profitieren wir von der verteilten Quellcodeverwaltung und würde sie für die Problemverfolgung gelten?

Einfaches Verzweigen und Zusammenführen : nicht wirklich. Eigentlich ist es entscheidend, dass alle auf der gleichen Seite sind. Eine Verzweigung wäre also höchst unerwünscht.

Leistung : Die von einem Issue-Tracker übertragene Datenmenge ist eher gering, und das gesamte Heben erfolgt auf dem Server, sodass dies kein Problem darstellt.

Erweiterte Workflows (Push, Pull, Staging usw.): Issue-Tracker verfügen bereits über gute (und häufig hoch konfigurierbare) Workflows. Dafür brauchen wir kein verteiltes System. Im Gegenteil, es würde die Dinge viel schwieriger machen, da Sie mit widersprüchlichen Veränderungen umgehen müssen.

Offline-Funktionen : Sicher, diese wären schön. Diese können jedoch auch ohne vollständige Verteilung erworben werden.

Darüber hinaus wird die (verteilte) Quellcodeverwaltung fast ausschließlich von Programmierern verwendet. Die Problemverfolgung wird auch von Testern, Designern, technischen Redakteuren, Managern, Marketingmitarbeitern und manchmal sogar Endbenutzern verwendet. Diese weniger Menschen ohne Informatik-Hintergrund könnten Schwierigkeiten haben, die Feinheiten eines verteilten Systems zu verstehen.

oefe
quelle

Ich stelle mir vor, dass das verteilte Issue-Tracking genauso wie git auch als Server funktioniert. Ich würde erwarten, dass Entwickler es mit ihrem lokalen (möglicherweise manchmal offline) Setup verwenden und andere Leute es nur vom zentralen Server aus verwenden. Denken Sie, dass dies einige Ihrer Bedenken mildert?

Billy Moon

Ich denke nicht, dass Zusammenführungskonflikte ein großes Problem darstellen werden, da jeder neue Eintrag in einer Ausgabe von einem Zeitstempel begleitet wird. Daher sollten Zusammenführungskonflikte mithilfe dieser Zeitstempel leicht (automatisch vom Programm) gelöst werden können. Ich erwarte nicht, dass vorhandene Inhalte stark verändert werden. Halten Sie das für realistisch?

Billy Moon

Verwenden andere Personen die Problemverfolgung, bevor es ein Repo zum Teilen von Code gibt - oder bevor das Repo zum Verfolgen von Code verwendet wird?

Billy Moon

Ich stelle mir vor, dass es für kleine Projekte / Beratungsarbeiten sehr nützlich wäre, das Projekt auf verteilte Weise nachverfolgen zu können. Es wird dann automatisch Teil des Projektarchivs und macht es auch einfach, eine Form der Problemverfolgung einzurichten, ohne es als separate Einheit zu verwalten. Sehen Sie dies als potenziellen Vorteil?

Billy Moon

Eine enge Integration in das VCS würde es ermöglichen, den Issue-Tracker einfach auf dem neuesten Stand zu halten. Wenn ich offline etwas codiere, kann ich den integrierten Issue-Tracker aktualisieren lassen - möglicherweise ein Problem schließen - und später, wenn ich wieder verbunden bin, alle Änderungen am Code und die Probleme zusammenführen. Halten Sie das für realistisch / problematisch / nützlich?

Billy Moon

Ich denke nicht, dass Dezentralisierung so wichtig ist wie Offline-Funktionen. Die Integration in die Quellcodeverwaltung ist ein großer Vorteil. Sie möchten daher, dass jeder Benutzer beide Aufgaben bequem erledigen kann. Je näher sie zusammen kommen, desto mehr Kontinuität haben Sie.

Selbst die am meisten verteilten Teams sollten in der Lage sein, einen Webserver und ein Tracking-System zusammenzustellen. Es wäre vorteilhafter, einen zentralen Bug-Tracker zu haben, da jeder Benutzer nur eine Teilmenge der Bug-Datenbank benötigt. Bugs werden normalerweise jemandem zugewiesen, der individuell daran arbeiten kann. Es ist nichts Falsches daran, nicht für alle anderen verfügbar zu sein, wenn es eine Art "Check-out" -System verwendet, das es in einem schreibgeschützten Zustand belässt. Auf einer Website können Kunden / Benutzer auch ihre eigenen Tickets eingeben und anzeigen.

Sie haben etwas mit dem Offline-Bedarf zu tun, aber viele der Probleme, die Sie angesprochen haben, können vermieden werden, indem Sie nur Teile des Bug-Trackers auschecken, an denen Sie arbeiten können, während die Verbindung getrennt ist.

Für viele Benutzer ist E-Mail eines der besten Integrationstools, insbesondere wenn Sie Mitarbeiter außerhalb des Teams haben. Ich werde nicht zu Ihrer Website zurückkehren, um zu sehen, ob mein Problem behoben wurde. Ich möchte eine E-Mail mit einem möglichen Antwortlink, um Feedback zu geben. Jeder Entwickler, der auf eine Änderungsanforderungs-E-Mail antwortet, kann eine Antwort senden und im System verfolgen lassen.

JeffO
quelle

Für mich ist es am sinnvollsten, die Probleme in das Projekt-VCS aufzunehmen, damit alle Probleme verfügbar sind, und es ist ein Problem der Berichterstellung, die relevanten zu extrahieren. Ich denke, der Overhead für das Repo ist akzeptabel. Was denkst du? Was einen zentralen Server betrifft, stelle ich mir ein System nach git vor, dessen Implementierung vollständig verteilt ist, aber Sie können es auf einem Server hosten, den Sie als zentralen Server bezeichnen (wie z. B. github). Irgendwelche Gedanken?

Billy Moon

Die aktiven Themen sind die relevanten. Ich bin mir nicht sicher, wie weit zurück in der Geschichte meine lokale Fehlerdatenbank gehen soll. Ich bin mit dir auf dem zentralen, ähnlich wie Github. Ich stelle mir den Bug-Tracking-Teil eher als eine Aufgabenliste vor, die mit dem Code verknüpft ist, und nicht als Kopie der gesamten Datenbank.

JeffO

Ist diese Sorge auf das Problem zurückzuführen, irrelevante Daten zu sichten? oder aus Sicht des Stauraums?

Billy Moon

@BillyMoon - Ich denke nicht, dass die Speicherung so problematisch ist wie die Zeit, um die Tracking-Einträge aller zu synchronisieren. Es ist vielleicht keine große Sache, aber ich stelle es immer noch in den Kontext der verteilten Anrufverfolgung, anstatt nur einen Eintrag auf einer Website zu machen.

JeffO

Ich werde wirklich spezifisch über tatsächliche Produkte sein. Einige werden das wahrscheinlich mögen und andere vielleicht nicht, aber hier ist:

Ich habe im Laufe der Jahre eine Reihe von Tools für die Nachverfolgung von Problemen, Aufgaben und Projekten verwendet. Microsoft Project, Trello und Jira haben alle ihren Platz gehabt.

Jetzt benutze ich Pivotal Tracker. Ich mag die Raffinesse und die einfache Bedienung und ich mag die Art und Weise, wie andere Leute Tickets bearbeiten und aktualisieren, diese Änderungen auch in Ihrem Fenster vornehmen und hervorheben. Es ist also bei weitem der beste "Netzwerk" -Stil dieser Tools, den ich habe. habe es versucht.

Ich bin mir nicht ganz sicher, ob du das mit verteilt meinst, aber los geht's.

Wenn ja, würde ich mich daran gewöhnen und dann die Mängel von Pivotal Tracker (falls vorhanden) für Sie prüfen, bevor ich eine Alternative entwickle.

Michael Durrant
quelle