Ein Check ist eine einzelne Verifizierung. Ein Run ist eine Ausführung der Checks in einer Richtlinie gegen eine Änderung. Ein Ergebnis ist etwas, das ein Check gemeldet hat.
Die Ergebnisse zu einer Aufgabe finden Sie im Qualitätskontrolle Abschnitt – jeder Ausführungsvorgang wird in den Einstellungen → Aktivität.
Einen Run lesen
Ein Run zeigt jeden Check, sein Ergebnis und seine Ausgabe. Wenn eine Aufgabe die Verifizierung nicht besteht, finden Sie im Run den Grund dafür.
Lesen Sie ihn von oben nach unten. Der erste fehlgeschlagene Check ist meist der eigentliche Grund – spätere Fehler sind häufig Folgen davon. Ein Build-Fehler mit anschließenden zwölf Testfehlern repräsentiert ein Problem, nicht dreizehn.
Ergebnisse
Die Ergebnisse stammen von Rezensions-Agenten, Scannern und Prüfgates. Jedes Ergebnis gibt an, was gefunden wurde, wo und wie schwerwiegend es ist. Ein Ergebnis zu einer Aufgabe bleibt dieser Aufgabe zugeordnet. Ein Testfehler, der zu keiner Aufgabe gehört, wartet in der Factory unter dem Reiter Rezension darauf, dass Sie ihn beheben oder aus einem bestimmten Grund akzeptieren. Eine Prüfung, die in einem Projekt nicht ausgeführt werden kann – etwa Unit-Tests ohne ein Testframework –, wird in der Qualitätskontrolle in ihrer jeweiligen Zeile entsprechend angezeigt.
Ihr Lebenszyklus:
- Erstellt durch einen Check oder einen Reviewer.
- Geroutet – reparable Ergebnisse werden dem Entwickler-Agenten zur Nachbearbeitung zurückgegeben; die übrigen werden dem pull request zugeordnet.
- Gelöst – behoben, akzeptiert oder ignoriert.
Erkannt
- Ein beratender Prüfpunkt
Der Revisor-Agent- Ein verbundener Scanner
Zugeordnet
Behebbar
Zurück an den Entwickler als Nacharbeit
Alles andere
Dem pull request beigefügt
Gelöst
Behoben
Die Änderung behebt das Problem.
Akzeptiert
Richtig, hier lohnt eine Bearbeitung nicht. Nennen Sie den Grund.
Unterdrückt
Ein Fehlalarm oder eine nicht anwendbare Regel. Nennen Sie den Grund.
Priorisieren
Die Frage zu jedem Ergebnis lautet nicht „Stimmt das?“ sondern „Ändert das das weitere Vorgehen?“
- Sofort beheben – Korrektheit, Sicherheit – alles, was ohnehin die Überprüfung nicht bestehen würde.
- Akzeptieren – korrekt, aber hier nicht handlungsbedürftig. Begründen Sie dies.
- Ignorieren – ein Fehlalarm oder eine Regel, die auf diesen Code nicht zutrifft.
Ignorieren Sie gezielt und mit Begründung. Eine unbegründete Ignorierung ist nicht von jemandem zu unterscheiden, der eine unangenehme Wahrheit verschweigt – und nach sechs Monaten kann niemand mehr sagen, um welches es sich handelte.
Wenn es zu viele Ergebnisse gibt
Die Menge ist ein Signal für die Konfiguration, nicht für die Codequalität.
Ein Check, der bei den meisten Änderungen ausgelöst wird, findet keine Probleme – er beschreibt Ihren Codebestand. Entweder passt die Regel nicht zu Ihren Konventionen, oder sie beschreibt Schulden, die Sie zu tolerieren bereit sind. Beides bedeutet, dass der Check die falsche Form hat.
Ergebnisse und Schranken
Ein Ergebnis aus einer beratenden Schranke ist Information. Dasselbe Ergebnis aus einer blockierenden Schranke stoppt die Aufgabe. Das Ergebnis ist identisch; die Richtlinie bestimmt die Folgen.
Das ist der Hebel, den man nutzt, wenn ein Check richtig, aber zu aggressiv ist: Ändern Sie seine Schweregradstufe statt ihn zu entfernen. Siehe Qualitätsrichtlinien und Schranken.