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 preparazione al rilascio
Le revisioni del codice di preparazione al rilascio valutano le modifiche apportate al codice in base ai rischi di dipendenza tra repository diversi, alla conformità agli standard interni e alla correttezza del controllo degli accessi. Esegue inoltre test di verifica automatizzati, ovvero 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 di preparazione al rilascio, completa i seguenti passaggi di configurazione.
Passaggio 1: abilita le funzionalità nei tuoi repository
Le funzionalità di revisione del codice e di test automatizzato devono essere abilitate sui GitLab repository connessi GitHub o sugli archivi prima che possano essere attivate.
La sezione Code Review and Automated Testing nelle impostazioni di integrazione del provider di pipeline offre due funzionalità per archivio:
Attivazione automatica della revisione delle modifiche: se abilitata, DevOps Agent esegue automaticamente una revisione del codice di preparazione al rilascio ogni volta che una pull request o una richiesta di unione viene aperta o aggiornata. I risultati della revisione vengono visualizzati come commenti in linea su. PR/MR
Test di verifica automatizzati: se abilitati, DevOps Agent crea, esegue e verifica le modifiche al codice in un ambiente di verifica gestito durante le revisioni del codice. Ciò fornisce una convalida funzionale oltre all'analisi statica. Per ulteriori informazioni, consulta Test di verifica automatizzati.
Puoi abilitare o disabilitare ogni funzionalità in modo indipendente per archivio, in modo da 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 registri di pacchetti privati o 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 connetti 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 automatizzati.
Fase 2: Configurare l'accesso privato al VPC per l'ambiente di test di verifica (opzionale)
Le revisioni del codice di preparazione al rilascio possono eseguire test di verifica automatizzati creando, 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 archivi di immagini privati (ad esempio Artifactory, Docker Hub Enterprise), archivi di artifatti di build interni o repository di codice dipendenti, devi fornire all'ambiente di test di verifica l'accesso a un VPC in grado di raggiungere quegli endpoint del servizio.
Per impostazione predefinita, l'ambiente di test di verifica non ha accesso di rete ai sistemi interni. Per abilitare l'accesso, create una connessione privata e associatela al vostro fornitore 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 all'ambiente di costruzione l'accesso di rete ai servizi interni.
Nota
L'integrazione con i VPC nel tuo account indirizza il traffico di rete attraverso i percorsi interni, rispettando tutte le restrizioni di rete in vigore.
Per configurare l'accesso privato al VPC per i test di verifica:
Crea una connessione privata destinata al VPC dove sono raggiungibili i tuoi servizi di build 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 fornitore della pipeline (GitHub o GitLab).
Nella sezione Code Review and Automated Testing, associa la connessione privata al fornitore della 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 essere autorizzato ad accedere a AWS Secrets Manager nello stesso AWS account del tuo Agent Space. Ti consigliamo di utilizzare un ruolo diverso da quello 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 le build di revisione del codice.
Esecuzione di una revisione del codice
Puoi richiedere una revisione del codice su richiesta tramite la chat DevOps dell'agente:
«Rivedi la filiale feature/payments sul servizio di pagamento contro pronti contro termine per verificare i rischi di rilascio»
«Rivedi il commit abc123 sull'infrastruttura repo per verificarne la disponibilità al rilascio»
«Quali rischi di rilascio esistono nelle ultime modifiche apportate al servizio di ordini pronti contro termine?»
L'agente valuta l'ambito specificato (una filiale, un commit o un insieme di modifiche) e restituisce un rapporto sullo stato di preparazione 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: passaggi attuabili per risolvere ogni problema
Le revisioni vengono generalmente 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 utilizza il plugin Kiro Power o Claude Code, l'agente di codifica può richiamare una revisione della disponibilità al 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 eccessivamente autorizzate o preparando modifiche dipendenti in altri repository.
Revisioni del codice nelle richieste pull e nelle richieste di unione
Quando le PR/MR revisioni automatiche sono abilitate, l'agente esamina ogni nuova pull request e richiesta di unione nei repository collegati. Le recensioni si attivano quando:
Ne PR/MR viene aperto uno nuovo
I nuovi commit vengono trasferiti 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 Puoi configurare se i risultati bloccano le unioni (controllo dello stato obbligatorio) o se sono solo indicativi.
Test di verifica automatizzati
Quando viene attivata una valutazione del rischio di idoneità al rilascio, DevOps Agent crea un ambiente AWS di verifica gestito in cui 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, lo storage 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 correttamente l'applicazione, l'agente genera un piano di test e lo esegue per identificare i rischi funzionali, ad esempio casi limite che potrebbero causare guasti o comportamenti imprevisti.
I risultati dei test di verifica sono inclusi nel rapporto di preparazione alla versione finale 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 build valida 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 di autorizzazioni 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 dei sorgenti |
Nota
Se la tua applicazione richiede l'accesso alla rete a domini non presenti in questo elenco, puoi connettere l'ambiente di test di verifica a un VPC. In questo modo l'agente utilizzerà le tue impostazioni del firewall di rete, consentendoti di configurare l'accesso a tutti i servizi richiesti dall'applicazione.
Revisione dei risultati della revisione del codice
Ogni revisione del codice produce un rapporto accessibile nella pagina Modifiche dell'app web DevOps Agent. I report includono:
Individuazione delle categorie: violazioni delle politiche, rischi di dipendenza, problemi di controllo degli accessi e lacune nella copertura dei test
Livelli di gravità: blocco (da correggere 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 IAM nella riga 42?» o «Quali repository dipendono dall'endpoint API che ho modificato?»
Integrazione con Kiro IDE e CLI
Per utilizzare le revisioni del codice di preparazione al rilascio in Kiro:
Installa DevOps Agent Kiro Power dal marketplace di Kiro Power
The Power include competenze che indicano all'agente di codifica quando richiamare le revisioni di disponibilità al rilascio, dopo importanti modifiche al codice e prima di creare un PR
I risultati emergono 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à al rilascio e incorporerà i risultati nel suo flusso di lavoro.
Integrazione con Claude Code
Per utilizzare le revisioni del codice di preparazione al rilascio in Claude Code:
Installa il plugin DevOps Agent Claude Code
Il plugin collega Claude Code al tuo Agent Space e consente all'agente di codifica di richiamare le revisioni sulla disponibilità al rilascio
Durante lo sviluppo, Claude Code può richiedere una revisione delle modifiche in corso e correggere i risultati prima di impegnarsi
Integrazione con AWS Trasforma personalizzata
Per utilizzare le revisioni del codice di preparazione al rilascio in AWS Transform custom:
Scarica la skill AWS DevOps Agent Release Readiness Code Reviews dal repository di esempi personalizzati AWS Transform su
. 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 verifica della disponibilità al rilascio rispetto alle modifiche proposte.
Esamina la superficie dei risultati direttamente nell'output Transform. Se vengono identificati problemi, Transform può risolverli prima di finalizzare la modifica del codice.
Utilizzo delle revisioni del codice in GitHub
Prerequisiti: GitHub repository collegato 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 tra le pull request, con un commento generale sullo stato
Configura come controllo di stato obbligatorio per bloccare le unioni quando esistono risultati di blocco
L'agente esamina tutti i PR per impostazione predefinita; il filtraggio dei percorsi e dei rami è configurabile nelle impostazioni di Agent Space
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 della richiesta di unione per richiedere la risoluzione dei risultati di blocco
L'agente esamina tutti gli MR per impostazione predefinita; il filtraggio dei percorsi e dei rami è configurabile nelle impostazioni di Agent Space
Utilizzo delle revisioni del codice nella DevOps chat di Agent
Da DevOps Agent chat, puoi:
Richiedere revisioni di qualsiasi ambito di filiale, commit o repository
Chiedi cosa sa l'agente sulle dipendenze del tuo progetto: «Quali basi di codice interagiscono con il servizio incluso nel repository dei pagamenti?»
Poni 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 sulla disponibilità al rilascio includono barriere di sicurezza integrate che impediscono i comuni comportamenti non sicuri degli agenti. Questi guardrail sono sempre attivi durante il processo di revisione. La copertura specifica e il comportamento di applicazione possono cambiare man mano che la funzionalità si evolve. Il nostro obiettivo è quello di coprire il maggior numero possibile di comportamenti non sicuri comuni, ma per alcuni comportamenti non saranno previste barriere corrispondenti.
Prevenzione dell'esposizione alle credenziali
L'agente blocca qualsiasi chiamata allo strumento in cui l'input dello strumento contiene schemi di credenziali comuni in testo semplice, come AWS chiavi, token di accesso e chiavi private.
Rilevamento sensibile dell'esfiltrazione di file
L'agente analizza e blocca i comandi della shell che combinano l'accesso a percorsi di file sensibili con le operazioni di rete, prevenendo 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 in fase sequenziale
Le fasi di revisione della disponibilità al rilascio devono essere eseguite in sequenza. Ciò garantisce una valutazione sistematica e approfondita e impedisce che le valutazioni incomplete vengano saltate.
