Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Revisioni del codice di disponibilità al rilascio
Le revisioni del codice relativo alla disponibilità al rilascio valutano le modifiche apportate al codice per individuare i rischi di dipendenza tra diversi repository, la conformità agli standard interni e la correttezza del controllo degli accessi. Esegue inoltre test di verifica automatici (crea, esegue e verifica le modifiche al codice) in un ambiente di verifica gestito dall'agente. AWS DevOps
Nozioni di base
Per utilizzare le revisioni del codice pronto per il rilascio, completa i seguenti passaggi di configurazione.
Passaggio 1: abilita le funzionalità nei tuoi repository
Le funzionalità di revisione del codice e di test automatici devono essere abilitate sui repository connessi GitHub o sui GitLab repository prima di poter essere attivate.
La sezione Code Review and Automated Testing nelle impostazioni di integrazione del provider di pipeline offre due funzionalità per repository:
Revisione automatica delle modifiche: se abilitata, DevOps l'agente esegue automaticamente una revisione del codice di idoneità alla versione ogni volta che una pull request o una merge request viene aperta o aggiornata. I risultati delle recensioni vengono visualizzati come commenti in linea su. PR/MR
Test di verifica automatizzato: se abilitato, DevOps l'agente crea, esegue e verifica le modifiche al codice in un ambiente di verifica gestito durante le revisioni del codice. Ciò fornisce una convalida funzionale che va oltre l'analisi statica. Per ulteriori informazioni, vedere Test di verifica automatizzati.
Puoi abilitare o disabilitare ciascuna funzionalità indipendentemente per repository, consentendoti di utilizzare le revisioni delle modifiche senza test di verifica o viceversa.
La sezione include anche:
Ruolo di runtime (opzionale): scegli il ruolo IAM che DevOps l'agente assume per eseguire funzionalità automatizzate sui repository selezionati. Questo ruolo viene utilizzato quando si accede ai servizi interni durante le build, come i registri privati dei pacchetti o gli archivi di artefatti. Per ulteriori informazioni, consulta Fase 2.
Per GitHub: accedi alla sezione Code Review and Automated Testing nelle impostazioni di GitHub integrazione e abilita le funzionalità per ogni repository. Entrambe le funzionalità sono abilitate per impostazione predefinita quando si collegano i repository. Per istruzioni dettagliate, consulta Configurazione della revisione del codice e dei test automatizzati.
Per GitLab: accedi alla sezione Code Review and Automated Testing nelle impostazioni di GitLab integrazione e abilita le funzionalità per i tuoi progetti. Per istruzioni dettagliate, consulta Configurazione della revisione del codice e dei test automatici.
Passaggio 2: configurare l'accesso privato al VPC per l'ambiente di test di verifica (opzionale)
Le revisioni del codice relativo alla disponibilità al rilascio possono eseguire test di verifica automatici compilando, eseguendo e testando le modifiche al codice in un ambiente di verifica (vedi Test di verifica automatizzati). Se il processo di creazione del codice richiede artefatti provenienti da sistemi interni, come repository di immagini privati (ad esempio, Artifactory, Docker Hub Enterprise), archivi di artefatti di compilazione interni o repository di codice dipendenti, è necessario fornire all'ambiente di test di verifica l'accesso a un VPC in grado di raggiungere tali endpoint di servizio.
Per impostazione predefinita, l'ambiente di test di verifica non dispone dell'accesso di rete ai sistemi interni. Per abilitare l'accesso, create una connessione privata e associatela al vostro provider di pipeline (GitHubo GitLab). L'ambiente di test di verifica utilizza il VPC associato a quella connessione privata creando e gestendo un ENI all'interno del VPC, fornendo alla rete dell'ambiente di compilazione l'accesso alla rete dei servizi interni.
Nota
L'integrazione con i VPC nel tuo account indirizza il traffico di rete attraverso i percorsi interni, seguendo eventuali restrizioni di rete in vigore.
Per configurare l'accesso privato al VPC per i test di verifica:
Crea una connessione privata indirizzata al VPC dove sono raggiungibili i tuoi servizi di compilazione interni. Per istruzioni, consulta Connessione a strumenti ospitati privatamente.
Apri la console dell' AWS DevOps agente e accedi al tuo Agent Space.
Vai alla scheda Funzionalità e seleziona il tuo fornitore di pipeline (GitHub o GitLab).
Nella sezione Code Review and Automated Testing, associa la connessione privata al tuo provider di pipeline selezionandola tra le connessioni disponibili.
Per il ruolo Runtime, seleziona un ruolo IAM che DevOps l'agente assumerà quando accede ai servizi interni durante le build. Questo ruolo deve disporre dell'autorizzazione per accedere a AWS Secrets Manager nello stesso AWS account del tuo Agent Space. Ti consigliamo di utilizzare un ruolo diverso dal tuo ruolo di agente principale.
Scegli Salva per applicare la configurazione.
Una volta associato, l'ambiente di test di verifica fornirà un ENI nel VPC della connessione privata, consentendogli l'accesso diretto alla rete ai servizi interni durante la compilazione della revisione del codice.
Esecuzione di una revisione del codice
Puoi richiedere una revisione del codice su richiesta tramite DevOps Agent chat:
«Esamina la filiale feature/payments sul servizio di pagamento con termine di rimborso per i rischi di rilascio»
«Controlla il commit abc123 sull'infrastruttura repo per verificarne l'idoneità al rilascio»
«Quali rischi di rilascio esistono nelle ultime modifiche al repo order-service?»
L'agente valuta l'ambito specificato (un ramo, un commit o una serie di modifiche) e restituisce un rapporto sulla disponibilità al rilascio. Il rapporto include:
Azione consigliata: BLOCCA, PROCEDI CON CAUTELA O RILASCIO SICURO
Riepilogo delle modifiche: cosa è stato modificato e portata dell'impatto
Analisi del rischio: risultati specifici con le posizioni dei codici interessate
Raccomandazioni: misure attuabili per risolvere ogni risultato
Le revisioni in genere vengono completate in 8-10 minuti, a seconda delle dimensioni e della complessità della modifica.
Revisioni automatiche del codice
Le revisioni automatiche del codice vengono eseguite senza intervento manuale. Possono attivarsi in due contesti:
Revisioni del codice durante la generazione del codice
Quando si utilizza il plug-in Kiro Power o Claude Code, l'agente di codifica può richiamare una revisione della disponibilità del rilascio durante la generazione del codice. La revisione valuta le modifiche in corso rispetto alle politiche e alle dipendenze, facendo emergere i risultati direttamente nell'IDE prima che il codice venga eseguito.
Se vengono rilevati problemi, l'agente di codifica riceve una notifica e può risolverli immediatamente, correggendo le violazioni delle policy, correggendo le policy IAM con autorizzazioni eccessive o preparando modifiche dipendenti in altri repository.
Revisioni del codice nelle richieste pull e merge
Quando le PR/MR revisioni automatiche sono abilitate, l'agente esamina ogni nuova pull request e merge request nei repository collegati. Le recensioni si attivano quando:
Ne PR/MR viene aperto uno nuovo
I nuovi commit vengono inviati a uno esistente PR/MR
I risultati vengono visualizzati come commenti in linea sulle righe di codice interessate, con la valutazione complessiva pubblicata come commento. PR/MR È possibile configurare se i risultati bloccano le unioni (verifica dello stato obbligatoria) o sono solo consultivi.
Limitazione degli archivi pubblici
I trigger automatici di revisione del PR/MR codice sono disponibili solo per gli archivi privati. DevOps L'agente non esamina automaticamente le pull request o le richieste di merge negli archivi pubblici.
Poiché chiunque può aprire una pull request su un archivio pubblico, inclusi collaboratori esterni sconosciuti, l'attivazione automatica delle revisioni su tali PR potrebbe consumare risorse senza che il proprietario del repository ne sia a conoscenza o elaborare contenuti non attendibili. La limitazione dei trigger automatici agli archivi privati garantisce che solo collaboratori fidati avviino il flusso di revisione.
Se utilizzi un archivio pubblico, puoi comunque eseguire revisioni del codice di preparazione alla versione richiedendole tramite DevOps Agent chat o tramite le integrazioni degli agenti di codifica (Kiro Power, plug-in Claude Code o Transform custom). AWS
Test di verifica automatizzati
Quando viene avviata una valutazione del rischio di idoneità al rilascio, DevOps l'agente crea un ambiente AWS di verifica gestito e vi clona il codice. L'ambiente funziona su risorse di elaborazione dedicate con restrizioni di rete che limitano l'accesso a servizi affidabili per la compilazione, l'archiviazione degli artefatti e il recupero.
DevOps L'agente legge il codice e i file di progetto dell'applicazione per determinare gli strumenti di compilazione e le dipendenze necessari, quindi li installa nell'ambiente di verifica. Dopo aver creato con successo l'applicazione, l'agente genera un piano di test e lo esegue per identificare i rischi funzionali, ad esempio i casi limite che potrebbero causare errori o comportamenti imprevisti.
I risultati dei test di verifica sono inclusi nel rapporto finale di preparazione al rilascio insieme ai risultati relativi agli standard, alle dipendenze e al controllo degli accessi.
È possibile utilizzare Istruzioni per l'agente (AGENTS.md) per ottimizzare il modo in cui vengono eseguiti i test di verifica, ad esempio specificando quali comandi di test eseguire, cosa costituisce una compilazione superata o quali parti dell'applicazione utilizzare durante la verifica.
Destinazioni di rete consentite
L'ambiente di test di verifica ha l'accesso alla rete in uscita limitato a una lista consentita predefinita. L'applicazione può raggiungere i seguenti domini durante la convalida:
| Dominio | Scopo |
|---|---|
.amazonaws.com, .aws.amazon.com |
AWS servizi |
.public.ecr.aws |
Amazon ECR Public |
.docker.com, .docker.io |
Docker Hub |
.github.com, .githubusercontent.com |
GitHub |
.gitlab.com |
GitLab |
.npmjs.com, .npmjs.org |
registro npm |
.pypi.org, .pypi.python.org, .pythonhosted.org |
Indice dei pacchetti Python |
.crates.io, .rustup.rs |
Pacchetti Rust |
.maven.org, .gradle.org |
Java/Gradle pacchetti |
.nuget.org |
pacchetti.NET |
.rubygems.org, .ruby-lang.org |
Pacchetti Ruby |
.golang.org, .pkg.go.dev, .goproxy.io |
Pacchetti Go |
.nodejs.org, .yarnpkg.com |
Node.js |
.alpinelinux.org, .debian.org, .ubuntu.com, .centos.org, .fedoraproject.org |
Repository di distribuzione Linux |
.cloudfront.net |
CloudFront distribuzioni |
.google.com, .googleapis.com |
API di Google |
.microsoft.com, .visualstudio.com |
Servizi Microsoft |
.sourceforge.net, .bitbucket.org |
Hosting di origine |
.prisma.sh |
Prisma ORM |
get.helm.sh |
Gestore di pacchetti Helm |
.terraform.io |
Registro Terraform |
buf.build |
Buf (Protobuf) |
.jitpack.io |
JitPack (pacchetti JVM) |
.scala-sbt.org |
Scala SBT |
.sheetjs.com |
Foglio JS |
.confluent.io |
Confluente (Kafka) |
.external-secrets.io |
Operatore segreto esterno |
registry.npmmirror.com |
registro mirror npm |
Nota
Se la tua applicazione richiede l'accesso alla rete a domini non presenti in questo elenco, puoi connettere il tuo ambiente di test di verifica a un VPC: l'agente utilizzerà le tue impostazioni del firewall di rete, consentendoti di configurare l'accesso a qualsiasi servizio richiesto dall'applicazione.
Revisione dei risultati della revisione del codice
Ogni revisione del codice produce un report accessibile nella pagina Releases dell'app web DevOps Agent. I report includono:
Ricerca delle categorie: violazioni delle policy, rischi di dipendenza, problemi di controllo degli accessi e lacune nella copertura dei test
Livelli di gravità: blocco (deve essere risolto prima dell'unione), avviso (deve essere risolto) e informativo (solo consapevolezza)
Diario di esecuzione: traccia completa delle fasi e degli strumenti di valutazione utilizzati dall'agente, che fornisce trasparenza sul modo in cui sono state raggiunte le conclusioni
Puoi anche porre domande di follow-up nella chat DevOps dell'agente: «Perché la revisione ha segnalato la modifica dello IAM nella riga 42?» o «Quali repository dipendono dall'endpoint API che ho modificato?»
Effettua l'integrazione con l'IDE e la CLI di Kiro
Per utilizzare le revisioni del codice di preparazione al rilascio in Kiro:
Installa l'DevOps Agent Kiro Power
dal marketplace di Kiro Power Il Power include competenze che indicano all'agente di codifica quando richiamare le revisioni della disponibilità al rilascio, dopo modifiche significative al codice e prima di creare un PR
I risultati vengono visualizzati direttamente nell'IDE e Kiro si offrirà di risolvere i problemi identificati
Dalla CLI di Kiro, puoi anche attivare le revisioni in modo esplicito: l'agente di codifica richiamerà la revisione della disponibilità del rilascio e incorporerà i risultati nel suo flusso di lavoro.
Effettua l'integrazione con Claude Code
Per utilizzare le revisioni del codice di preparazione al rilascio in Claude Code:
Installa il plugin DevOps Agent Claude Code
dal marketplace dei plugin Claude Code Il plugin collega Claude Code al tuo Agent Space e consente all'agente di codifica di richiamare le revisioni della disponibilità al rilascio
Durante lo sviluppo, Claude Code può richiedere una revisione delle modifiche in corso e risolvere i problemi riscontrati prima di effettuare il commit
Integra con AWS Trasforma personalizzata
Per utilizzare le revisioni del codice di preparazione al rilascio in AWS Transform custom:
Scarica l'abilità AWS DevOps Agent Release Readiness Code Review dal repository di esempi personalizzati di
AWS Transform in poi. GitHub Installa la skill nel tuo ambiente AWS Transform seguendo le istruzioni nel repository README.
Una volta installata, la skill si integra con il flusso di lavoro di generazione del codice di AWS Transform. Quando Transform genera o modifica il codice, la skill richiama una revisione della disponibilità al rilascio rispetto alle modifiche proposte.
I risultati della revisione vengono visualizzati direttamente nell'output di Transform. Se vengono identificati dei problemi, Transform può risolverli prima di finalizzare la modifica del codice.
Utilizzo delle revisioni del codice in GitHub
Prerequisiti: GitHub repository connesso al tuo Agent Space con revisioni automatiche abilitate. Per le istruzioni di configurazione, consulta Configurazione della revisione del codice e dei test automatizzati.
Le recensioni vengono visualizzate come commenti in linea nelle differenze delle pull request, con un commento generale sullo stato
Configura come controllo di stato obbligatorio per bloccare le unioni quando esistono risultati di blocco
Utilizzo delle revisioni del codice in GitLab
Prerequisiti: GitLab progetto connesso al tuo Agent Space con revisioni automatiche abilitate. Per le istruzioni di configurazione, consulta Configurazione della revisione del codice e dei test automatizzati.
Le recensioni vengono visualizzate come commenti in linea sulle differenze delle richieste di unione, con una nota generale
Configura come regola di approvazione delle richieste di unione per richiedere la risoluzione dei risultati del blocco
Utilizzo delle revisioni del codice nella chat degli DevOps agenti
Dalla chat DevOps dell'agente, puoi:
Richiedi revisioni di qualsiasi filiale, commit o ambito di repository
Chiedi cosa sa l'agente sulle dipendenze del tuo progetto: «Quali basi di codice interagiscono con il servizio nel repository dei pagamenti?»
Fai domande di follow-up su risultati specifici
Richiedi all'agente di generare una correzione per un problema identificato
Visualizza il grafico delle conoscenze sulle dipendenze per i tuoi repository connessi
Parapetti di sicurezza Agentic
Le revisioni della disponibilità al rilascio includono protezioni di sicurezza integrate che impediscono i comuni comportamenti non sicuri degli agenti. Questi parapetti sono sempre attivi durante il processo di revisione. La copertura specifica e il comportamento di applicazione possono cambiare con l'evolversi della funzionalità. Sebbene il nostro obiettivo sia coprire il maggior numero possibile di comportamenti pericolosi comuni, alcuni comportamenti non prevedono misure di protezione corrispondenti.
Prevenzione dell'esposizione alle credenziali
L'agente blocca qualsiasi chiamata allo strumento in cui l'input dello strumento contiene modelli di credenziali comuni in testo normale, come AWS chiavi, token di accesso e chiavi private.
Rilevamento dell'esfiltrazione di file sensibili
L'agente analizza e blocca i comandi della shell che combinano l'accesso a percorsi di file sensibili con le operazioni di rete, impedendo i tentativi di esfiltrazione dei dati.
Mutativo AWS blocco delle operazioni
L'agente blocca qualsiasi chiamata AWS API che potrebbe modificare l'infrastruttura. Ciò impedisce all'agente di revisione di apportare modifiche all' AWS ambiente durante l'analisi. Read-only le operazioni (describe, get, list) sono consentite; le operazioni mutative sono bloccate.
Read-only operazioni come describe_*get_*, e list_* sono consentite.
Applicazione sequenziale in fasi
Le fasi di revisione della disponibilità al rilascio devono essere eseguite in sequenza. Ciò garantisce una valutazione sistematica e completa ed evita che le valutazioni incomplete vengano saltate.
