CoroidIhre AI Software-Fabrik
Dokumentation

Wie Coroid seine eigene Arbeit überprüft

Warum ein pull request aus Coroid bereits überprüft vorliegt und welche Aussage jede Überprüfungsebene tatsächlich trifft.

Ein pull request von Coroid durchläuft vor der Anzeige eine Verifizierung. Dieser Abschnitt erläutert, was das bedeutet und wie Sie es konfigurieren können.

Die Ebenen

Verifizierung ist nicht einheitlich – vier Ebenen arbeiten, jede beantwortet eine andere Frage.

Ihr Test-Suite. Der stärkste verfügbare Indikator, da er bereits widerspiegelt, was Ihr Team als wichtig erachtet. Coroid führt ihn in einem sauberen Arbeitsbereich für jede Aufgabe aus.

Qualitäts-Gates. Richtlinienbasierte Prüfungen – Abdeckung, Linting, Sicherheitsscans, Browser-Tests und die Globalisierungs-Prüfung für mehrsprachige Projekte. Blockierende Gates stoppen die Aufgabe; beratende Gates zeichnen einen Befund auf und erlauben die Fortsetzung. Sehen Sie sich Qualitäts-Richtlinien und Gates.

Rezension. Ein Rezensions-Agent liest den fertigen Diff und erstellt Befunde. Behebbare Befunde werden dem Entwickler zur Nachbesserung zurückgegeben; die übrigen werden dem pull request zugeordnet.

Nachweise. Vorschau-Deployments, Scan-Ergebnisse und Abdeckungs-Unterschiede werden dem pull request selbst zugeordnet, sodass die Verifizierung mit dem Code einhergeht. Sehen Sie sich Rezensions-Nachweise.

  1. Ihr Test-SuiteStört die Änderung das Bestehende?
  2. Qualitäts-GatesErfüllt sie die in Ihren Richtlinien festgelegten Standards?
  3. ReviewWürde ein aufmerksamer Leser des Diffs die Änderung akzeptieren?
  4. NachweiseIst der Nachweis dem Code beigefügt?
  5. Ihr ReviewIst dies die richtige Änderung?

Jede automatisierte Ebene läuft vor der Erstellung des pull request, sodass Fehler als Nacharbeit innerhalb des Laufs auftreten.

Jede automatisierte Ebene beantwortet eine andere Frage. Keine von ihnen entscheidet, ob dies die richtige Lösung ist – das bleibt bei Ihnen.

Was dies beweist und was nicht

Die Verifizierung bestätigt, dass die Änderung das tut, was sie soll, das Bestehende nicht stört und den von Ihnen festgelegten Standards entspricht.

Sie beweist nicht dass die Änderung das Richtige zum Bauen ist. Dafür dienen die Annahmekriterien in der Spezifikation und Ihre Rezension.

Eine Änderung kann alle Ebenen bestehen und dennoch falsch sein. Diese klare Unterscheidung sorgt dafür, dass der Rest vertrauenswürdig bleibt – sobald die Verifizierung als Urteil dargestellt wird, hören die Menschen auf zu rezensieren.

Der Sinn des frühen Ausführens

Jede Ebene läuft vor der Erstellung des pull request ab, sodass Fehler als Nachbesserungsaufgaben innerhalb des Durchlaufs zurückkommen – statt als ein pull request, das Sie nur ablehnen würden.

Es ist günstiger, im Arbeitsbereich zu scheitern als auf Ihrem Bildschirm. Ihre Rezension sollte der erste menschliche Blick sein, nicht der erste Eindruck.

Wo Sie beginnen sollten

Falls Sie dies zum ersten Mal konfigurieren:

  1. Stellen Sie sicher, dass Ihre Test-Suite funktioniert – sehen Sie sich Build- und Test-Konfiguration. Alles andere spielt keine Rolle, wenn dies nicht korrekt ist.
  2. Legen Sie eine organisationsweite Standard-Richtlinie auf Ihrer Standard Ebene fest, nicht auf der strengsten.
  3. Verbinden Sie die Nachweis-Anbieter, die Sie bereits nutzen.
  4. Fügen Sie die Gates einzeln hinzu, zuerst die beratenden.

In diesem Abschnitt