Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Überprüfung des Bereitschaftscodes für die Freigabe
Bei Code-Reviews zur Veröffentlichungsreife werden Ihre Codeänderungen auf Repository-übergreifende Abhängigkeiten, die Einhaltung interner Standards und die Richtigkeit der Zugriffskontrolle hin überprüft. Es führt auch automatische Verifizierungstests durch — es erstellt, führt und testet Ihre Codeänderungen — in einer vom Agenten verwalteten Prüfungsumgebung. AWS DevOps
Erste Schritte
Führen Sie die folgenden Einrichtungsschritte durch, um Codeüberprüfungen für die Releasebereitschaft zu verwenden.
Schritt 1: Aktivieren Sie Funktionen in Ihren Repositorys
Die Funktionen für Codeüberprüfung und automatisiertes Testen müssen in deinen verbundenen Repositorys GitHub oder GitLab Repositorys aktiviert sein, bevor sie ausgelöst werden können.
Der Abschnitt Codeüberprüfung und automatisiertes Testen in den Integrationseinstellungen Ihres Pipeline-Providers bietet zwei Funktionen pro Repository:
Change Review automatisch auslösen — Wenn diese Option aktiviert ist, führt der DevOps Agent jedes Mal, wenn ein Pull Request oder Merge Request geöffnet oder aktualisiert wird, automatisch eine Codeüberprüfung für die Release-Bereitschaft durch. Die Ergebnisse der Überprüfung werden als eingebettete Kommentare auf der angezeigt PR/MR.
Automatisierte Überprüfungstests — Wenn diese Option aktiviert ist, erstellt, führt und testet der DevOps Agent Ihre Codeänderungen während der Codeüberprüfungen in einer verwalteten Überprüfungsumgebung. Dies ermöglicht eine Funktionsvalidierung, die über die statische Analyse hinausgeht. Weitere Informationen finden Sie unter Automatisierte Verifizierungstests.
Du kannst jede Funktion unabhängig pro Repository aktivieren oder deaktivieren, sodass du Change Reviews ohne Verifizierungstests verwenden kannst oder umgekehrt.
Der Abschnitt beinhaltet auch:
Runtime-Rolle (optional) — Wählen Sie die IAM-Rolle aus, die der DevOps Agent annimmt, um automatisierte Funktionen auf Ihren ausgewählten Repositorys auszuführen. Diese Rolle wird verwendet, wenn während der Builds auf interne Dienste zugegriffen wird, wie z. B. private Paketregistrierungen oder Artefaktspeicher. Weitere Informationen finden Sie in Schritt 2.
Für GitHub: Navigieren Sie in Ihren GitHub Integrationseinstellungen zum Abschnitt Codeüberprüfung und automatisiertes Testen und aktivieren Sie die Funktionen für jedes Repository. Beide Funktionen sind standardmäßig aktiviert, wenn Sie Repositorys verbinden. Eine ausführliche Anleitung finden Sie unter Konfiguration der Codeüberprüfung und des automatisierten Testens.
Für GitLab: Navigieren Sie in Ihren GitLab Integrationseinstellungen zum Abschnitt Codeüberprüfung und automatisiertes Testen und aktivieren Sie die Funktionen für Ihre Projekte. Eine ausführliche Anleitung finden Sie unter Konfiguration von Code-Review und automatisiertem Testen.
Schritt 2: Konfigurieren Sie den privaten VPC-Zugriff für die Verifizierungstestumgebung (optional)
Mit Codeüberprüfungen zur Versionsreife können automatisierte Verifizierungstests durchgeführt werden, indem Ihre Codeänderungen in einer Verifikationsumgebung erstellt, ausgeführt und getestet werden (siehe Automatisierte Verifizierungstests). Wenn Ihr Code-Build-Prozess Artefakte aus internen Systemen erfordert — wie etwa private Image-Repositorys (z. B. Artifactory, Docker Hub Enterprise), interne Build-Artefaktspeicher oder abhängige Code-Repositorys — müssen Sie der Prüfungstestumgebung Zugriff auf eine VPC gewähren, die diese Service-Endpunkte erreichen kann.
Standardmäßig hat die Verifizierungstestumgebung keinen Netzwerkzugriff auf Ihre internen Systeme. Um den Zugriff zu ermöglichen, erstellen Sie eine private Verbindung und verknüpfen Sie sie mit Ihrem Pipeline-Anbieter (GitHuboder GitLab). Die Verifizierungstestumgebung verwendet die mit dieser privaten Verbindung verknüpfte VPC, indem sie eine ENI innerhalb der VPC erstellt und verwaltet, wodurch die Build-Umgebung Netzwerkzugriff auf Ihre internen Dienste erhält.
Anmerkung
Durch die Integration von VPCs in Ihrem Konto wird der Netzwerkverkehr über Ihre internen Routen geleitet, wobei alle geltenden Netzwerkeinschränkungen eingehalten werden.
So konfigurieren Sie den privaten VPC-Zugriff für Verifizierungstests:
Erstellen Sie eine private Verbindung, die auf die VPC abzielt, auf der Ihre internen Build-Services erreichbar sind. Detaillierte Anweisungen finden Sie unter Verbindung zu privat gehosteten Tools herstellen.
Öffnen Sie die AWS DevOps Agentenkonsole und navigieren Sie zu Ihrem Agentenbereich.
Gehen Sie zur Registerkarte „Funktionen“ und wählen Sie Ihren Pipeline-Anbieter (GitHub oder GitLab) aus.
Ordnen Sie im Abschnitt Codeüberprüfung und automatisiertes Testen die private Verbindung Ihrem Pipeline-Anbieter zu, indem Sie sie aus den verfügbaren Verbindungen auswählen.
Wählen Sie für die Runtime-Rolle eine IAM-Rolle aus, die der DevOps Agent übernimmt, wenn er während der Builds auf interne Dienste zugreift. Diese Rolle muss berechtigt sein, mit demselben AWS Konto wie Ihr Agent Space auf AWS Secrets Manager zuzugreifen. Wir empfehlen, eine andere Rolle als Ihre primäre Agentenrolle zu verwenden.
Wählen Sie Speichern, um Ihre Konfiguration zu übernehmen.
Nach der Verknüpfung stellt die Verifizierungstestumgebung eine ENI in der VPC der privaten Verbindung bereit, sodass diese während der Codeüberprüfung direkten Netzwerkzugriff auf Ihre internen Dienste hat.
Durchführung einer Code-Überprüfung
Sie können bei Bedarf eine Code-Überprüfung über den DevOps Agenten-Chat anfordern:
„Überprüfen Sie die Filiale feature/payments des Repo-Zahlungsdienstes auf Veröffentlichungsrisiken“
„Überprüfe, ob Commit abc123 die Repo-Infrastruktur bereit für die Veröffentlichung ist“
„Welche Release-Risiken bergen die neuesten Änderungen am Repo-Bestellservice?“
Der Agent bewertet den angegebenen Umfang — einen Branch, ein Commit oder eine Reihe von Änderungen — und gibt einen Bericht über die Veröffentlichungsbereitschaft zurück. Der Bericht beinhaltet:
Empfohlene Maßnahme — BLOCKIEREN, Vorsicht walten lassen oder Sicher loslassen
Zusammenfassung der Änderungen — Was wurde geändert und Umfang der Auswirkungen
Risikoanalyse — Spezifische Ergebnisse mit den betroffenen Codepositionen
Empfehlungen — Umsetzbare Schritte zur Behebung der einzelnen Befunde
Prüfungen werden in der Regel in 8—10 Minuten abgeschlossen, je nach Umfang und Komplexität der Änderung.
Automatisierte Code-Reviews
Automatisierte Code-Reviews werden ohne manuelles Eingreifen ausgeführt. Sie können in zwei Kontexten ausgelöst werden:
Codeüberprüfungen während der Codegenerierung
Wenn Sie das Kiro Power- oder Claude Code-Plugin verwenden, kann der Coding-Agent während der Codegenerierung eine Überprüfung der Release-Readiness durchführen. Bei der Überprüfung werden die laufenden Änderungen anhand Ihrer Richtlinien und Abhängigkeiten bewertet. Die Ergebnisse werden direkt in der IDE angezeigt, bevor der Code festgeschrieben wird.
Wenn Probleme gefunden werden, wird der Coding-Agent benachrichtigt und kann diese sofort beheben. Er kann Richtlinienverstöße korrigieren, IAM-Richtlinien korrigieren, die zu viele Berechtigungen haben, oder abhängige Änderungen in anderen Repositorys vorbereiten.
Codeüberprüfungen in Pull Requests und Merge-Requests
Wenn automatische PR/MR Reviews aktiviert sind, überprüft der Agent jeden neuen Pull Request und Merge Request in deinen verbundenen Repositorys. Bewertungen werden ausgelöst, wenn:
Ein neues PR/MR wird geöffnet
Neue Commits werden an einen bestehenden übertragen PR/MR
Die Ergebnisse werden als Inline-Kommentare zu den betroffenen Codezeilen angezeigt, wobei die Gesamtbewertung als PR/MR Kommentar veröffentlicht wird. Sie können konfigurieren, ob die Ergebnisse Zusammenführungen blockieren (erforderliche Statusüberprüfung) oder nur als Empfehlung dienen.
Beschränkung des öffentlichen Repositorys
Automatisierte PR/MR Codeüberprüfungs-Trigger sind nur für private Repositorys verfügbar. DevOps Der Agent überprüft nicht automatisch Pull-Requests oder Merge-Requests in öffentlichen Repositorys.
Da jeder einen Pull-Request für ein öffentliches Repository öffnen kann — einschließlich unbekannter externer Mitwirkender — könnte das automatische Auslösen von Reviews auf diesen PRs Ressourcen verbrauchen, ohne dass der Repository-Besitzer davon Kenntnis hat, oder nicht vertrauenswürdige Inhalte verarbeiten. Die Beschränkung automatisierter Trigger auf private Repositorys stellt sicher, dass nur vertrauenswürdige Mitarbeiter den Review-Workflow initiieren.
Wenn du ein öffentliches Repositorium verwendest, kannst du trotzdem Code-Reviews durchführen, indem du sie im DevOps Agenten-Chat oder über Coding-Agent-Integrationen (Kiro Power, Claude Code-Plugin oder Transform custom) anforderst. AWS
Automatisierte Verifizierungstests
Wenn eine Risikobewertung der Release-Readiness ausgelöst wird, erstellt der DevOps Agent eine AWS verwaltete Überprüfungsumgebung und klont Ihren Code darin. Die Umgebung läuft auf dedizierten Rechenressourcen mit Netzwerkeinschränkungen, die den Zugriff auf vertrauenswürdige Dienste zum Erstellen, Speichern und Abrufen von Artefakten einschränken.
DevOps Der Agent liest den Code und die Projektdateien Ihrer Anwendung, um die erforderlichen Build-Tools und Abhängigkeiten zu ermitteln, und installiert sie dann in der Verifizierungsumgebung. Nach der erfolgreichen Erstellung Ihrer Anwendung generiert der Agent einen Testplan und führt ihn aus, um funktionale Risiken zu identifizieren — z. B. Randfälle, die zu Ausfällen oder unerwartetem Verhalten führen können.
Die Ergebnisse der Verifizierungstests sind zusammen mit den Ergebnissen zu Standards, Abhängigkeiten und Zugriffskontrollen im endgültigen Bericht über die Veröffentlichungsbereitschaft enthalten.
Sie können Anweisungen für Agenten (AGENTS.md) verwenden, um zu optimieren, wie Verifizierungstests durchgeführt werden. Sie können beispielsweise angeben, welche Testbefehle ausgeführt werden sollen, was einen erfolgreichen Build ausmacht oder welche Teile der Anwendung während der Überprüfung ausgeführt werden sollen.
Erlaubte Netzwerkziele
In der Testumgebung zur Überprüfung ist der ausgehende Netzwerkzugriff auf eine vordefinierte Zulassungsliste beschränkt. Ihre Anwendung kann während der Validierung die folgenden Domänen erreichen:
| Domain | Zweck |
|---|---|
.amazonaws.com, .aws.amazon.com |
AWS Dienstleistungen |
.public.ecr.aws |
Amazon ECR Public |
.docker.com, .docker.io |
Docker Hub |
.github.com, .githubusercontent.com |
GitHub |
.gitlab.com |
GitLab |
.npmjs.com, .npmjs.org |
npm-Registrierung |
.pypi.org, .pypi.python.org, .pythonhosted.org |
Python-Paketindex |
.crates.io, .rustup.rs |
Rust-Pakete |
.maven.org, .gradle.org |
Java/Gradle Pakete |
.nuget.org |
.NET-Pakete |
.rubygems.org, .ruby-lang.org |
Ruby-Pakete |
.golang.org, .pkg.go.dev, .goproxy.io |
Go-Pakete |
.nodejs.org, .yarnpkg.com |
Node.js |
.alpinelinux.org, .debian.org, .ubuntu.com, .centos.org, .fedoraproject.org |
Repositorys für Linux-Distributionen |
.cloudfront.net |
CloudFront Distributionen |
.google.com, .googleapis.com |
Google-APIs |
.microsoft.com, .visualstudio.com |
Microsoft-Dienste |
.sourceforge.net, .bitbucket.org |
Hosting an der Quelle |
.prisma.sh |
Prisma ORM |
get.helm.sh |
Helm-Paketmanager |
.terraform.io |
Terraform-Registrierung |
buf.build |
Aber (Protobuf) |
.jitpack.io |
JitPack (JVM-Pakete) |
.scala-sbt.org |
Scala SBT |
.sheetjs.com |
Blatt JS |
.confluent.io |
Konfluent (Kafka) |
.external-secrets.io |
Operator für externe Geheimnisse |
registry.npmmirror.com |
NPM-Spiegelregistrierung |
Anmerkung
Wenn Ihre Anwendung Netzwerkzugriff auf Domänen benötigt, die nicht in dieser Liste aufgeführt sind, können Sie Ihre Verifizierungstestumgebung mit einer VPC verbinden. Dadurch verwendet der Agent Ihre eigenen Netzwerk-Firewall-Einstellungen, sodass Sie den Zugriff auf alle Dienste konfigurieren können, die Ihre Anwendung benötigt.
Die Ergebnisse der Codeüberprüfung werden überprüft
Bei jeder Codeüberprüfung wird ein Bericht erstellt, auf den Sie auf der Seite „Versionen“ der DevOps Agent-Web-App zugreifen können. Zu den Berichten gehören:
Suche nach Kategorien — Richtlinienverstöße, Abhängigkeitsrisiken, Probleme mit der Zugriffskontrolle und Lücken in der Testabdeckung
Schweregrade — Blockieren (muss vor dem Zusammenführen behoben werden), Warnung (sollte behoben werden) und Informativ (nur zur Sensibilisierung)
Ausführungstagebuch — Der vollständige Überblick über die vom Agenten verwendeten Bewertungsschritte und Tools bietet Transparenz darüber, wie die Ergebnisse gezogen wurden
Im DevOps Agenten-Chat können Sie auch weitere Fragen stellen: „Warum wurde bei der Überprüfung die IAM-Änderung in Zeile 42 gemeldet?“ oder „Welche Repositorys hängen von dem API-Endpunkt ab, den ich geändert habe?“
Integrieren Sie mit Kiro IDE und CLI
Um Codeüberprüfungen zur Versionsreife in Kiro zu verwenden:
Installieren Sie den DevOps Agenten Kiro Power
vom Kiro Power-Marktplatz Die Power beinhaltet Skills, die dem Programmierer sagen, wann er nach wichtigen Codeänderungen und vor der Erstellung eines PR Readiness Reviews durchführen muss
Die Ergebnisse werden direkt in der IDE angezeigt, und Kiro bietet an, festgestellte Probleme zu beheben
Über die Kiro-CLI können Sie auch explizit Überprüfungen auslösen: Der Coding-Agent ruft die Überprüfung der Veröffentlichungsbereitschaft auf und integriert die Ergebnisse in seinen Arbeitsablauf.
Integrieren Sie mit Claude Code
Um Codeüberprüfungen zur Versionsbereitschaft in Claude Code zu verwenden:
Installieren Sie das DevOps Agent Claude Code-Plugin
vom Claude Code-Plug-in-Marktplatz Das Plugin verbindet Claude Code mit Ihrem Agent Space und ermöglicht es dem Coding-Agenten, Überprüfungen der Veröffentlichungsbereitschaft durchzuführen
Während der Entwicklung kann Claude Code eine Überprüfung der laufenden Änderungen anfordern und die Ergebnisse vor der Freigabe prüfen
Integrieren mit AWS Benutzerdefiniert transformieren
So verwenden Sie Codeüberprüfungen zur Versionsbereitschaft in AWS Transform custom:
Laden Sie den Skill für Codeüberprüfungen zur Versionsbereitschaft von AWS DevOps Agenten aus dem AWS Transform-Repository
für benutzerdefinierte Beispiele herunter GitHub. Installieren Sie den Skill in Ihrer AWS Transform-Umgebung, indem Sie den Anweisungen in der Readme-Datei des Repositorys folgen.
Nach der Installation lässt sich der Skill in den Workflow zur Codegenerierung von AWS Transform integrieren. Wenn Transform Code generiert oder ändert, veranlasst der Skill eine Überprüfung der Veröffentlichungsbereitschaft der vorgeschlagenen Änderungen.
Die Ergebnisse der Überprüfung werden direkt in der Transform-Ausgabe angezeigt. Wenn Probleme festgestellt werden, kann Transform diese beheben, bevor die Codeänderung abgeschlossen wird.
Mithilfe von Code-Reviews in GitHub
Voraussetzungen: Mit Ihrem Agent Space verbundenes GitHub Repository mit aktivierten automatischen Überprüfungen. Anweisungen zur Einrichtung finden Sie unter Konfiguration der Codeüberprüfung und des automatisierten Testens.
Bewertungen werden in Pull-Request-Diffs als Inline-Kommentare mit einem allgemeinen Statuskommentar angezeigt
Konfiguriere es als erforderliche Statusüberprüfung, um Zusammenführungen zu blockieren, wenn blockierende Ergebnisse vorliegen
Verwenden von Code-Reviews in GitLab
Voraussetzungen: GitLab Projekt, das mit Ihrem Agent Space verbunden ist und bei dem automatische Überprüfungen aktiviert sind. Anweisungen zur Einrichtung finden Sie unter Konfiguration der Codeüberprüfung und des automatisierten Testens.
Bewertungen werden in den Diffs zu Merge-Requests als eingebettete Kommentare mit einer allgemeinen Anmerkung angezeigt
Als Regel für die Genehmigung von Zusammenführungsanfragen konfigurieren, sodass die Behebung blockierender Ergebnisse erforderlich ist
Verwenden von Code-Reviews im DevOps Agenten-Chat
Vom DevOps Agenten-Chat aus können Sie:
Reviews für jeden Branch-, Commit- oder Repository-Bereich anfordern
Fragen Sie, was der Agent über die Abhängigkeiten Ihres Projekts weiß: „Welche Codebasen interagieren mit dem Service im Zahlungs-Repo?“
Stellen Sie Folgefragen zu bestimmten Ergebnissen
Bitten Sie den Agenten, eine Lösung für ein identifiziertes Problem zu erstellen
Sehen Sie sich das Abhängigkeits-Wissensdiagramm für Ihre verbundenen Repositorys an
Agentic Sicherheitsleitplanken
Zur Überprüfung der Veröffentlichungsreife gehören integrierte Sicherheitsvorkehrungen, die das übliche unsichere Verhalten von Agenten verhindern. Diese Schutzmaßnahmen sind während des Überprüfungsprozesses immer aktiv. Das spezifische Erfassungs- und Durchsetzungsverhalten kann sich im Zuge der Weiterentwicklung der Funktion ändern. Wir sind zwar bestrebt, so viele gängige unsichere Verhaltensweisen wie möglich abzudecken, aber für einige Verhaltensweisen gibt es keine entsprechenden Schutzmaßnahmen.
Schutz vor der Gefährdung durch Zugangsdaten
Der Agent blockiert jeden Toolaufruf, bei dem die Tool-Eingabe gängige Muster von Anmeldeinformationen im Klartext enthält, wie AWS Schlüssel, Zugriffstoken und private Schlüssel.
Erkennung vertraulicher Dateien
Der Agent scannt und blockiert Shell-Befehle, die den Zugriff auf vertrauliche Dateipfade mit Netzwerkoperationen kombinieren und so Versuche der Datenexfiltration verhindern.
Mutativ AWS Blockierung der Operation
Der Agent blockiert jeden AWS API-Aufruf, der Ihre Infrastruktur verändern würde. Dadurch wird verhindert, dass der Review-Agent während der Analyse Änderungen an Ihrer AWS Umgebung vornimmt. Read-only Operationen (describe, get, list) sind zulässig; mutative Operationen werden blockiert.
Read-only Operationen wie describe_*get_*, und list_* sind zulässig.
Schrittweise Durchsetzung
Die Phasen der Überprüfung der Veröffentlichungsbereitschaft müssen nacheinander durchgeführt werden. Dies gewährleistet eine systematische und gründliche Bewertung und verhindert, dass unvollständige Bewertungen übersprungen werden.
