--- title: "Repositoryübergreifende Reviews · Docs · SourceAnt" description: "Dokumentation: Code-Reviews über mehrere Repositories hinweg einrichten: Gruppieren Sie Repositories zu einem System, finden Sie die Verbindungen und lesen Sie ein Review, das einer Änderung in alles folgt, was sie erreicht." url: "https://sourceant.ai/de/docs/cross-repository-reviews/" --- # 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](https://sourceant.ai/de/docs/systems). ## 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 initialisieren**lautet, 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 Imports_lautet, 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 **ausstehend**an. 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. | Verbindungsstatus | Was 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_, _Bereitstellung_, _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 - [Code-Review](https://sourceant.ai/de/docs/code-review): womit eine Änderung sonst noch abgeglichen wird. - [Knowledge-Management](https://sourceant.ai/de/docs/knowledge-management): die Entscheidungen und Einschränkungen, die eine Prüfung neben dem Graphen liest. - [Systems and cross-repository reviews](https://sourceant.ai/de/systems): wie die Karte erstellt und ehrlich gehalten wird.