System- und repositoryübergreifende Reviews
Ein Pull Request bindet ein Repository. Ihre Änderung endet nicht dort. SourceAnt zeichnet die Dienste, Komponenten, Queues und Datenspeicher auf, die zusammenarbeiten, und verwendet dann diese Karte, um eine Änderung gegen alles zu überprüfen, was sie erreicht, und benennt die Repositories, die es nicht lesen konnte, anstatt sie zu überspringen.
Jeder Entwickler und jeder Agent inklusive, nie pro Seat · Ihre eigenen Modellschlüssel
Die Überprüfung
Jedes Review-Tool liest den Diff, der vor ihm liegt. Wenn der Vertrag, den Sie gerade geändert haben, von einem Service in einem anderen Repository konsumiert wird, ist der Diff die Hälfte der Geschichte, die Ihnen das nicht sagen kann. SourceAnt beginnt bei den geänderten Dateien, folgt dem Graphen zu allem, was sie erreichen, und liest auch dort.
Ausgehend von den geänderten Dateien folgt das Review dem Graphen zu den Services, Queues und Datastores am anderen Ende. Bestätigte Verknüpfungen werden als solche ausgewiesen. Ausstehende werden als Frage aufgeworfen, niemals als Tatsache.
In jedem Repository, das es erreicht, sucht es nach dem Code, der das berührt, was Sie geändert haben, und zitiert ihn mit dem Repository und der Revision, aus der er stammt. Sie können die genannte Datei öffnen.
Ein Repository, das nicht erreicht wurde, wird im Review mit dem Grund genannt. Ein Reviewer, der stillschweigend die Hälfte Ihres Systems überspringt, ist schlechter als einer, der die Lücke eingesteht.
Gelesen aus den Manifesten, die Ihre Repositories bereits veröffentlichen, über die API. Nichts wird geklont, nichts wird ausgeführt, und kein Modell rät. Jede Kante nennt die Datei, aus der sie stammt, und nichts wird ohne eine Person bestätigt.
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.
Woher es das weiß
Ein Review kann nur so weit reichen wie der Graph hinter ihm. Jede andere Architekturkarte ist eine Momentaufnahme, die jemand einmal erstellt hat. Diese hier ist ein Kreislauf: die Quelle der Wahrheit lesen, die Differenz vorschlagen, auf Sie warten und eingestehen, wenn sie veraltet ist.
package.json, composer.json, go.mod, requirements.txt und pyproject.toml, abgerufen über die GitHub API. Ein Manifest, das sich nicht parsen lässt, schlägt nichts vor, statt das gesamte System scheitern zu lassen.
Eine Abhängigkeit wird vorgeschlagen, wenn ein Repository einen Namen deklariert, unter dem sich ein anderes selbst veröffentlicht. Jeder Vorschlag nennt das Manifest, aus dem er stammt, sodass Sie ihn durch Öffnen einer Datei prüfen können.
Vorschläge kommen als ausstehend an und bleiben ausstehend. Nichts hier bestätigt sich selbst. Senden Sie zuerst persist: false, wenn Sie den Vorschlag sehen möchten, ohne den Graphen überhaupt zu berühren.
Ein Teil, der als veraltet gilt, wird eher als veraltet markiert denn gelöscht. Der Eintrag sagt, dass er unsicher ist, statt stillschweigend falsch zu werden – das ist das Versagen, das jede Architekturzeichnung hat.
Belege, keine Behauptungen
Eine Beziehung, die Sie nicht prüfen können, ist ein Gerücht. Jede trägt mit sich, woher sie stammt, wie sicher sie ist und ob jemand sie abgesegnet hat.
billing-api depends_on shared-auth ausstehend
Ein bloßer Name ist kein Beweis dafür, dass die Abhängigkeit zu Ihnen aufgelöst wird. Eine öffentliche Registry kann denselben Namen tragen, und so funktioniert Dependency Confusion, weshalb ein nicht beanspruchter Name mit geringerer Confidence vorgeschlagen statt behauptet wird.
Bewusst begrenzt
Eine Traversierung gibt einen Teilgraphen zurück, den Sie untersuchen oder einem Modell geben können. Sie sagt Ihnen, wann sie stoppen musste, statt stillschweigend einen halben Graphen zurückzugeben.
| Feld | Standard | Range |
|---|---|---|
| depth | 2 | 1 bis 3 |
| direction | both | outbound, inbound, both |
| minimum_confidence | 0.0 | 0 bis 1 |
| include_stale | false | on oder off |
| entity_limit | 50 | bis zu 50 |
| relationship_limit | 100 | bis zu 100 |
Lesen Sie den Graphen direkt mit /api/topology/search und /api/topology/traverse, oder lassen Sie einen Agenten denselben Teilgraphen über ein Context Pack via MCP abrufen.
Warum kein Katalog
Entwicklerportale verlangen von einer Person, jeden Dienst zu registrieren, und vertrauen dem Eintrag dann für immer. Der Eintrag verfällt nicht laut. Er passt einfach nicht mehr zum Code, und niemand erfährt davon bis zu einem Vorfall.
Fragen
Was es liest, wie weit es geht und was es tut, wenn es nicht weiterkommt.
Was Systems möglich macht. Es ist eine Überprüfung, die nicht an dem Repository haltmacht, in dem der Pull Request geöffnet wurde. Sie beginnt bei den geänderten Dateien, folgt den Verbindungen in Ihrem System zu den Diensten, Queues und Datenspeichern am anderen Ende und liest den Code dort. Eine normale Überprüfung sieht einen Diff. Diese sieht, was der Diff erreicht.
Ja. Multi-Repo-Code-Überprüfung, repository-übergreifende Überprüfung und Polyrepo-Überprüfung bezeichnen alle dasselbe Problem: Die Änderung ist in einem Repository und die Konsequenz in einem anderen. Wir sagen repository-übergreifende Überprüfung, weil die Reichweite der Punkt ist, nicht wie viele Repositories Sie zufällig haben.
Jedes separat zu überprüfen gibt Ihnen ein Urteil pro Repository und niemanden, der sich ansieht, was zwischen ihnen läuft. Dort sind die Brüche: Eine Seite hat einen Vertrag geändert, den die andere Seite noch erwartet. Eine repository-übergreifende Überprüfung liest beide Seiten in einem Durchgang und zitiert den Code, den sie auf der anderen Seite gelesen hat, mit dem Repository und der Revision, aus der er stammt.
Es liest Ihren Code und findet heraus, was zusammengehört. Manche Verbindungen sind offensichtlich, wie wenn ein Repository von einem anderen abhängt. Andere ergeben sich nur aus dem Code. Sie können weitere benutzerdefinierte Verbindungen hinzufügen, und SourceAnt zeigt Ihnen Vorschläge, nachdem es Ihr System betrachtet hat.
Ja. Ein Monorepo zählt als ein Repository, sodass eine Änderung darin bereits gegen den Rest davon überprüft wird. Systems ist in einem Multi-Repo- oder Polyrepo-Setup wichtiger, wo die andere Seite einer Änderung in einem anderen Repository liegt. Sie helfen auch einem Monorepo, das mit etwas außerhalb seines eigenen Baums kommuniziert, wie einem Dienst, einer Queue oder einem Datenspeicher. Sie können diese als Teile hinzufügen, obwohl sie keinen Code zum Lesen haben.
Nein. Die Überprüfung überquert sie, ob die Verknüpfung genehmigt ist oder nicht. Die Genehmigung ändert, wie darüber gesprochen werden darf. Eine genehmigte Verknüpfung wird als Tatsache dargestellt, mit der Stelle, an der die Änderung die andere Seite brechen könnte. Eine ausstehende wird als Frage aufgeworfen und enthält keinen Vorschlag.
Es wird in der Überprüfung genannt, mit dem Grund. Es wird niemals stillschweigend übersprungen. Eine Überprüfung, die die Hälfte Ihres Systems stillschweigend überspringt, sieht genauso aus wie eine, die alles gelesen und nichts gefunden hat. Die üblichen Ursachen: Das Repository wurde nie gelesen, es ist verbunden, aber nicht im selben System, oder die App ist nicht darauf installiert.
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.
Die Einrichtung wird Schritt für Schritt behandelt in dem Leitfaden zur repository-übergreifenden Prüfung.
Graph-Snapshots sind portabel, gestreamt und werden beim Eingang validiert, und ein unterbrochener Schreibvorgang wird wiederhergestellt statt halb angewendet zu bleiben.
Über MCP ist der Bereich der authentifizierte Prinzipal. Über HTTP ist es ein Workspace-Anspruch auf dem Token, und ein Token ohne einen solchen wird abgelehnt.
Ein Teil ist, was Ihre Architektur einen Teil nennt: ein Dienst, eine Queue, ein Datastore, ein Job. SourceAnt zwingt Ihnen keine Art Liste auf.
Richten Sie es auf Repositories, die Sie bereits haben, genehmigen Sie den ersten Vorschlag, öffnen Sie dann eine Änderung an einem von ihnen und sehen Sie, was die Prüfung am anderen erreicht.