SourceAnt
EN

Repository-übergreifende Reviews

Repositoryübergreifende Reviews sind das, was Systems ermöglicht. Gruppieren Sie zusammengehörige Repositories zu einem System, und ein Review kann prüfen, wie sich eine Änderung auf den Code in jedem Repository auswirkt, das dieses System erreicht.

Gruppieren Sie zusammengehörige Repositories zu einem System und erfassen Sie deren Verbindungen, damit Reviews diesen Beziehungen folgen können. Diese Anleitung zeigt Ihnen, wie Sie das einrichten. Eine Einführung in Teile, Verbindungen und Discovery-Ergebnisse finden Sie unter Systeme.

Bevor Sie beginnen

  • Die Repositories sind verbunden, in der Cloud oder auf Ihrer eigenen Instanz.
  • Sie sind Owner oder Admin des Workspace oder es ist Ihr persönlicher. Ohne diese Berechtigung werden die Schaltflächen unten überhaupt nicht gerendert.

1. Jedes Repository lesen

Ein Repository geht nicht als bloßer Teil in ein System ein. Durch das Lesen wird ein eigenes System abgeleitet, benannt owner/repo, und das größere System besteht dann aus diesen kleineren.

Offen Systeme in der Seitenleiste. Wenn noch nichts modelliert wurde, sehen Sie Noch nichts modelliert und eine Schaltfläche System erstellen ; andernfalls verwenden Sie + in der Kopfzeile, die mit Tooltip versehen ist Neues System.

Der Drawer trägt den Titel System zeichnen. Unten, unter Noch nicht gelesen, ist jedes verbundene Repository ohne dahinterstehendes System mit einer Schaltfläche Jetzt lesen aufgeführt. Lesen Sie diejenigen, die Sie im System haben möchten.

Sie können dies auch auf der Seite eines Repositories tun, wo die Schaltfläche Von GitHub initialisierenlautet, oder Erneut lesen , wenn es zuvor gelesen wurde.

2. Das System erstellen, das sie enthält

Im selben Drawer:

  1. Die Repositories lesen, unter Was wie ein System aussieht, schlägt Gruppierungen vor. Jeder Vorschlag gibt an, woher er stammt: Aus einer deklarierten Abhängigkeit, Aus repositoryübergreifenden Importslautet, oder Nur aus Namen. Er erstellt von sich aus nichts.
  2. Name des Systems, zum Beispiel Billing.
  3. Was es ist: eine Zeile dazu, was zusammen verstanden werden muss, um es zu ändern.
  4. Innerhalb eines anderen Systems: lassen Sie es aktiviert Nichts. Dies ist ein eigenständiges System es sei denn, Sie verschachteln es.
  5. Systeme darin: markieren Sie die Repository-Systeme, die Sie in Schritt 1 gelesen haben. Sie werden Teil dieses Systems statt eigener Systeme.
  6. System erstellen.

Nur aus Namen ist es wert, sorgfältig gelesen zu werden. Ein Vorschlag, der auf nichts außer einem übereinstimmenden Namen beruht, ist der schwächste Beleg, den es gibt, und derjenige, der am ehesten manuell geprüft werden sollte.

3. Finden Sie die Verbindungen

Öffnen Sie das System. Klicken Sie auf das teilungsförmige Symbol direkt links neben dem + Button in der Kopfzeile. Sein Tooltip lautet Verbindungen finden: lesen Sie, womit diese verbunden sind, aus dem, was jede einzelne veröffentlicht und was ihr Code aussagt. Es erscheint, sobald das System Repository-Systeme enthält.

Es liest die Repositories im Hintergrund und meldet den Fortschritt, zum Beispiel 3 Repositories werden gelesen. dann 3 Repositories gelesen. 1 konnte nicht gelesen werden. Wenn es fertig ist, wechselt die Seite selbst zum Parts Tab. Bei einem großen Bestand kann es mehrere Minuten dauern; das Verlassen der Seite stoppt es nicht.

4. Genehmigen Sie, was real ist

Alles, was die Inferenz findet, kommt als ausstehendan. Nichts, was sie vorschlägt, wird als Tatsache behandelt, bis eine Person es bestätigt.

Drei Stellen, um sie durchzuarbeiten, alle mit derselben Funktion:

  • Die Triage-Karte oben auf der Seite Systems mit der Überschrift N Verbindungen zum Prüfen und sortiert nach Schwächster Beleg zuerst. Genehmigen oder Ablehnen für jede einzelne.
  • Der Verbindungen Abschnitt unter jedem System auf dem Parts Tab.
  • Architecture → Interactive, der Alle N behalten und Alle verwerfen für das schnelle Durcharbeiten eines Stapels hinzufügt.

Arbeiten Sie nach dem Prinzip Schwächster Beleg zuerst, was der Reihenfolge entspricht, die die Triage-Karte bereits vorgibt. Eine Verbindung, die aus einer deklarierten Abhängigkeit gelesen wurde, ist meistens richtig. Eine, die auf einer Namensübereinstimmung beruht, verdient die zehn Sekunden, die es dauert, die zitierte Datei zu öffnen.

Was die Genehmigung tatsächlich ändert

Dies ist der Teil, der es wert ist, verstanden zu werden, denn er entspricht nicht dem, was die meisten annehmen. Ein Review reicht in ein anderes Repository hinein unabhängig davon, ob die Verknüpfung genehmigt ist. Die Genehmigung steuert nicht die Reichweite. Sie ändert, wie das Review darüber sprechen darf.

VerbindungsstatusWas das Review tut
Genehmigt Es nennt die Reichweite als Tatsache und sagt, wo die Änderung die andere Seite brechen könnte.
Ausstehend Es wirft, was die Verknüpfung bedeuten würde, als Frage auf. Es behauptet es nicht und hängt keinen Vorschlag daran.

Ein nicht genehmigter Graph ist also kein defekter. Er ist ein leiserer. Durch die Genehmigung teilen Sie dem Reviewer mit, dass er sicher sein darf.

5. Lesen Sie ein Review

Öffnen Sie einen Pull Request in einem der Repositories. Das Review erhält einen Abschnitt dazu, was die Änderung erreicht: die Systeme am anderen Ende, den verwandten Code, den es gelesen hat, zitiert mit dem Repository und der Revision, aus der er stammt.

Ein Schwester-Repository wird in der Revision gelesen, in der es zuletzt indexiert wurde, weil ein Pull Request nur seine eigene fixiert. Wo diese Revision alt ist, sagt das Review es, statt sie als aktuell darzustellen.

Was es nicht lesen konnte

Ein Repository, das die Prüfung nicht erreichen konnte, wird in der Prüfung mit dem Grund genannt. Es wird nicht stillschweigend übersprungen.

Das ist der Unterschied zwischen einer Prüfung, auf die Sie sich verlassen können, und einer, auf die Sie sich nicht verlassen können. Eine Prüfung, die die Hälfte Ihres Systems stillschweigend überspringt, sieht identisch aus wie eine, die alles gelesen und nichts gefunden hat.

Die üblichen Ursachen, geordnet danach, wie oft sie sich als Antwort herausstellen:

  • Das Repository wurde nie gelesen, es steckt also kein System dahinter. Kehren Sie zu Schritt 1 zurück.
  • Es ist verbunden, gehört aber nicht zum selben System.
  • Die App ist darauf nicht installiert, es gibt also nichts abzurufen.

Bestandteile, die keine Repositories sind

Vieles, wovon ein System abhängt, hat keinen Code zum Lesen. Erweitern Sie auf dem Tab Parts ein System und verwenden Sie + Add , um Eine Ressource hinzuzufügen: einen Service, Database, Queue, External API, Deployment, Schema, Document, oder etwas anderes, das Sie selbst benennen.

Geben Sie ihr einen Name und einen Identifier, also die Bezeichnung, unter der sie tatsächlich existiert, damit jemand, der die Prüfung liest, sie finden kann.

Dinge manuell verbinden

Die Inferenz schlägt nur vor, worauf sie mit einer Datei verweisen kann. Wenn Sie von einer Verbindung wissen, die sie nicht sehen kann, verwenden Sie Add connections auf dem Tab Parts: wählen Sie Von und Zu, dann How they are joined. Die Optionen sind Depends on, Consumes, Provides, Exposes, Contains, Deploys, Tests und Dokumente.

Eine Verbindung, die Sie selbst hinzufügen, ist sofort genehmigt. Sie sind die Person, die sie genehmigt hätte.

Next