Wird der Verweis auf Fehler / Probleme in der Festschreibungsnachricht als bewährte Methode angesehen?

11

Ich arbeite an einem Projekt, in dem die Quellcodeverwaltung so eingerichtet ist, dass automatisch Notizen in den Bug-Tracker geschrieben werden. Wir schreiben einfach die Fehlerproblem-ID in die Festschreibungsnachricht und die Festschreibungsnachricht wird als Hinweis zum Fehler-Tracker hinzugefügt.

Ich kann nur ein paar Nachteile für diese Praxis sehen. Wenn irgendwann in der Zukunft der Quellcode von der Fehlerverfolgungssoftware getrennt wird (oder die gemeldeten Fehler / Probleme irgendwie verloren gehen). Oder wenn jemand in der Geschichte der Commits nachschaut, aber keinen Zugriff auf unseren Bug-Tracker hat.

Meine Frage ist, ob eine Fehler- / Problemreferenz in der Festschreibungsnachricht als bewährte Methode angesehen wird. Gibt es noch andere Nachteile?

programming-practices version-control issue-tracking

— Christian P.
quelle

10

Wir haben diese Praxis übernommen und sie funktioniert sehr gut für uns. Die enge Integration zwischen dem Versionskontrollsystem (VCS) und anderen von uns verwendeten Systemen, z. B. kontinuierliche Integration, Bug-Tracker usw., ist äußerst wertvoll. Wenn wir in Zukunft jemals etwas ändern, müssen wir sicherlich die Nebenwirkungen bewerten, einschließlich der Verbindungen zwischen dem VCS und dem Bug-Tracking-System.

Im Allgemeinen würde ich dies als gute Praxis ansehen. Für einige Tracking-Systeme stehen zusätzliche Optionen und Tools zur Verfügung, z. B. Bugtraq-Eigenschaften für Subversion (SVN). Dies deutet darauf hin, dass nicht wenige Menschen Wert in dieser Praxis sehen.

— Manfred
quelle

13

Wenn Sie wirklich sicherstellen möchten, dass keine Informationen verloren gehen, auch wenn Sie in Zukunft möglicherweise einen anderen Bug-Tracker verwenden oder Ihre Bug-Tracker-Daten irgendwie verschwinden, geben Sie einfach die Problem-ID und eine kurze Erklärung des Fehlers ein die Commit-Nachricht?

Fehler # 123 behoben: App nach Anmeldung abgestürzt

Dann haben Sie immer noch den Link aus dem Verlauf der Commits zum Bug-Tracker - und sollte der Bug-Tracker jemals nicht verfügbar sein, können Sie im Verlauf immer noch sehen, worum es bei diesem bestimmten Bug ging.

— Christian Specht
quelle

Wir machen das tatsächlich, damit wir nicht jedes Mal zum Bug-Tracker wechseln müssen, wenn wir den Verlauf der Commits durchsuchen.

— Christian P

Okay, dann würde ich es einfach so lassen, wie es ist. IMO, das ist der beste Weg, wie Sie es tun können!

— Christian Specht

1

Ja, guter Punkt. Das war jedoch sowieso meine Annahme. Nur die Fehler- / Problem-ID allein ist meiner Erfahrung nach nicht gut genug. Wenn Sie sich das Festschreibungsprotokoll ansehen, möchten Sie immer noch sehen, worum es bei jedem Festschreiben ging, z. B. was der Hauptgrund für diese Codeänderung war. Manchmal ist die Festschreibungsnachricht eher technischer Natur, während der Text für das Fehlerverfolgungssystem eher auf Benutzer der Software ausgerichtet ist.

— Manfred

Dies war im Allgemeinen die Standardpraxis, in der ich auch gearbeitet habe. Ich denke, es ist der richtige Weg, dies zu tun.

— Carson63000

+1 mach das immer! Ich habe gerade die Wartung eines Projekts übernommen, das mit Edelsteinen wie "Dies könnte die Ursache für Fehler 5423 gewesen sein" gefüllt ist. Wir haben keinen Zugriff auf ihren Bug-Tracker.

— Kryptic

2

Dies ist eine sehr verbreitete Praxis, und ich habe sie als äußerst praktisch empfunden. Ich verwende TRAC, damit ich den Codeverlauf lesen und zu der Aufgabe navigieren kann, die die Änderung ausgelöst hat, oder den Aufgabenverlauf lesen und zu den Codeänderungen navigieren kann.

"Wenn irgendwann in der Zukunft ..." Wenn Sie den Code vom Bug-Tracker trennen, ist der alte Revisionsverlauf wahrscheinlich nicht weiter von Interesse.

— Kevin Cline
quelle

2

Ich benutze diese Praxis auch und halte sie für sehr gut. Neben der Problem-ID füge ich eine kurze Beschreibung des Fehlers / der Funktion hinzu (normalerweise der Titel des Fehlerverfolgungssystems). Dies hilft oft, Zeit zu sparen, da ich nicht im Bug-Tracking-System nachschlagen muss (weil ich die Änderung erkenne) UND, wie Sie sagten, wenn ich das Bug-Tracking-System irgendwie verliere, bin ich nicht vollständig verloren.

— Nicolae Albu
quelle