Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Révisions du code de préparation à la publication
Les révisions du code de préparation des versions évaluent les modifications apportées à votre code en termes de risques de dépendance entre dépôts, de conformité aux normes internes et d'exactitude du contrôle d'accès. Il effectue également des tests de vérification automatisés (il crée, exécute et teste les modifications de votre code) dans un environnement de vérification géré par l' AWS DevOps Agent.
Prise en main
Pour utiliser les révisions de code de préparation aux versions, effectuez les étapes de configuration suivantes.
Étape 1 : Activez les fonctionnalités de vos référentiels
Les fonctionnalités de révision du code et de test automatique doivent être activées sur vos GitLab référentiels connectés GitHub avant de pouvoir être déclenchées.
La section Révision du code et tests automatisés des paramètres d'intégration de votre fournisseur de pipeline fournit deux fonctionnalités par référentiel :
Révision automatique des modifications : lorsque cette option est activée, DevOps l'agent effectue automatiquement une révision du code de préparation à la publication chaque fois qu'une pull request ou une demande de fusion est ouverte ou mise à jour. Les résultats de la révision apparaissent sous forme de commentaires en ligne sur le PR/MR.
Tests de vérification automatisés : lorsque cette option est activée, DevOps l'agent crée, exécute et teste les modifications de votre code dans un environnement de vérification géré lors des révisions de code. Cela permet une validation fonctionnelle au-delà de l'analyse statique. Pour plus d'informations, consultez la section Tests de vérification automatisés.
Vous pouvez activer ou désactiver chaque fonctionnalité indépendamment pour chaque référentiel, ce qui vous permet d'utiliser les révisions des modifications sans tests de vérification, ou vice versa.
La section comprend également :
Rôle d'exécution (facultatif) : choisissez le rôle IAM que l' DevOps agent assume pour exécuter des fonctionnalités automatisées sur les référentiels que vous avez sélectionnés. Ce rôle est utilisé lors de l'accès à des services internes pendant les builds, tels que des registres de packages privés ou des magasins d'artefacts. Pour de plus amples informations, consultez l’Étape 2.
Pour GitHub : Accédez à la section Révision du code et tests automatisés dans vos paramètres GitHub d'intégration et activez les fonctionnalités de chaque référentiel. Les deux fonctionnalités sont activées par défaut lorsque vous connectez des référentiels. Pour obtenir des instructions détaillées, consultez la section Configuration de la révision du code et des tests automatisés.
Pour GitLab : Accédez à la section Révision du code et tests automatisés dans vos paramètres GitLab d'intégration et activez les fonctionnalités de vos projets. Pour obtenir des instructions détaillées, consultez la section Configuration de la révision du code et des tests automatisés.
Étape 2 : configurer l'accès privé au VPC pour l'environnement de test de vérification (facultatif)
Les révisions du code de préparation des versions peuvent effectuer des tests de vérification automatisés en créant, exécutant et testant les modifications de votre code dans un environnement de vérification (voir Tests de vérification automatisés). Si votre processus de création de code nécessite des artefacts provenant de systèmes internes, tels que des référentiels d'images privés (par exemple, Artifactory, Docker Hub Enterprise), des magasins d'artefacts de génération internes ou des référentiels de code dépendants, vous devez autoriser l'environnement de test de vérification à accéder à un VPC capable d'atteindre ces points de terminaison de service.
Par défaut, l'environnement de test de vérification ne dispose pas d'un accès réseau à vos systèmes internes. Pour activer l'accès, créez une connexion privée et associez-la à votre fournisseur de pipeline (GitHubou GitLab). L'environnement de test de vérification utilise le VPC associé à cette connexion privée en créant et en gérant un ENI dans le VPC, donnant à l'environnement de création un accès réseau à vos services internes.
Note
L'intégration de VPC dans votre compte achemine le trafic réseau via vos itinéraires internes, en respectant les restrictions réseau en place.
Pour configurer l'accès privé à un VPC pour les tests de vérification, procédez comme suit :
Créez une connexion privée qui cible le VPC auquel vos services de build internes sont accessibles. Pour obtenir des instructions, veuillez consulter Connexion à des outils hébergés en privé.
Ouvrez la console de l' AWS DevOps agent et accédez à votre espace agent.
Accédez à l'onglet Fonctionnalités et sélectionnez votre fournisseur de pipeline (GitHub ou GitLab).
Dans la section Révision du code et tests automatisés, associez la connexion privée à votre fournisseur de pipeline en le sélectionnant parmi les connexions disponibles.
Pour le rôle Runtime, sélectionnez un rôle IAM que l' DevOps agent assumera lors de l'accès aux services internes pendant les builds. Ce rôle doit être autorisé à accéder à AWS Secrets Manager depuis le même AWS compte que votre espace agent. Nous vous recommandons d'utiliser un rôle différent de votre rôle d'agent principal.
Choisissez Enregistrer pour appliquer votre configuration.
Une fois associé, l'environnement de test de vérification fournira un ENI dans le VPC de la connexion privée, lui donnant un accès réseau direct à vos services internes lors de la création de révisions de code.
Réaliser une révision de code
Vous pouvez demander une révision de code à la demande via le chat de DevOps l'agent :
« Revoir la branche feature/payments sur le service de paiement des prises en pension pour tenir compte des risques de publication »
« Passez en revue le commit abc123 sur l'infrastructure de dépôt pour la préparation de la version »
« Quels sont les risques de publication liés aux dernières modifications apportées au service de commande des dépôts ? »
L'agent évalue la portée spécifiée (une branche, un commit ou un ensemble de modifications) et renvoie un rapport de préparation à la publication. Le rapport inclut :
Action recommandée : BLOQUER, PROCÉDER AVEC PRUDENCE OU LIBÉRER EN TOUTE SÉCURITÉ
Résumé des modifications — Ce qui a été modifié et l'ampleur de l'impact
Analyse des risques — Constatations spécifiques concernant les emplacements de code concernés
Recommandations — Étapes réalisables pour résoudre chaque constatation
Les révisions se terminent généralement en 8 à 10 minutes, selon l'ampleur et la complexité de la modification.
Révisions de code automatisées
Les révisions de code automatisées s'effectuent sans intervention manuelle. Ils peuvent se déclencher dans deux contextes :
Révisions de code lors de la génération de code
Lors de l'utilisation du plug-in Kiro Power ou Claude Code, l'agent de codage peut invoquer une évaluation de l'état de préparation des versions au fur et à mesure de la génération du code. La revue évalue les modifications en cours par rapport à vos politiques et dépendances, en présentant les résultats directement dans l'IDE avant que le code ne soit validé.
Si des problèmes sont détectés, l'agent de codage en est averti et peut les résoudre immédiatement, en corrigeant les violations des règles, en corrigeant les politiques IAM dont les autorisations sont excessives ou en préparant des modifications dépendantes dans d'autres référentiels.
Révisions de code dans les pull requests et les merge requests
Lorsque les PR/MR révisions automatisées sont activées, l'agent examine chaque nouvelle demande d'extraction et de fusion dans vos référentiels connectés. Les avis se déclenchent lorsque :
Un nouveau PR/MR est ouvert
Les nouveaux commits sont transférés vers un commit existant PR/MR
Les résultats apparaissent sous forme de commentaires en ligne sur les lignes de code concernées, l'évaluation globale étant publiée sous forme de PR/MR commentaire. Vous pouvez configurer si les résultats sont fusionnés par blocs (vérification de statut requise) ou s'ils sont uniquement consultatifs.
Limitation du dépôt public
Les déclencheurs de révision automatique PR/MR du code ne sont disponibles que pour les référentiels privés. DevOps L'agent n'examine pas automatiquement les demandes d'extraction ni les demandes de fusion sur les référentiels publics.
Étant donné que n'importe qui peut ouvrir une pull request concernant un dépôt public, y compris des contributeurs externes inconnus, le fait de déclencher automatiquement des révisions sur ces PR pourrait consommer des ressources à l'insu du propriétaire du référentiel ou traiter du contenu non fiable. La restriction des déclencheurs automatisés aux référentiels privés garantit que seuls des collaborateurs de confiance initient le flux de révision.
Si vous utilisez un référentiel public, vous pouvez toujours effectuer des révisions de code de préparation à la publication en les demandant via le chat de l' DevOps agent ou via les intégrations d'agents de codage (Kiro Power, plugin Claude Code ou AWS Transform custom).
Tests de vérification automatisés
Lorsqu'une évaluation des risques liés à la disponibilité des versions est déclenchée, l' DevOps Agent crée un environnement de vérification AWS géré et y clone votre code. L'environnement fonctionne sur des ressources informatiques dédiées avec des restrictions réseau qui limitent l'accès à des services fiables pour la génération, le stockage des artefacts et la récupération.
DevOps L'agent lit le code et les fichiers de projet de votre application pour déterminer les outils de génération et les dépendances requis, puis les installe dans l'environnement de vérification. Après avoir créé votre application avec succès, l'agent génère un plan de test et l'exécute pour identifier les risques fonctionnels, tels que les cas extrêmes susceptibles d'entraîner des défaillances ou des comportements inattendus.
Les résultats des tests de vérification sont inclus dans le rapport final de préparation de la version, aux côtés des résultats relatifs aux normes, à la dépendance et au contrôle d'accès.
Vous pouvez utiliser Instructions pour les agents (AGENTS.md) pour ajuster la manière dont les tests de vérification sont effectués, par exemple, en spécifiant les commandes de test à exécuter, ce qui constitue une version réussie ou les parties de l'application à exécuter pendant la vérification.
Destinations réseau autorisées
L'environnement de test de vérification dispose d'un accès réseau sortant limité à une liste d'autorisation prédéfinie. Votre candidature peut atteindre les domaines suivants lors de la validation :
| Domain | Objectif |
|---|---|
.amazonaws.com, .aws.amazon.com |
AWS services |
.public.ecr.aws |
Amazon ECR Public |
.docker.com, .docker.io |
Docker Hub |
.github.com, .githubusercontent.com |
GitHub |
.gitlab.com |
GitLab |
.npmjs.com, .npmjs.org |
registre npm |
.pypi.org, .pypi.python.org, .pythonhosted.org |
Index des packages Python |
.crates.io, .rustup.rs |
Packages Rust |
.maven.org, .gradle.org |
Java/Gradle colis |
.nuget.org |
Packages .NET |
.rubygems.org, .ruby-lang.org |
Paquets Ruby |
.golang.org, .pkg.go.dev, .goproxy.io |
Forfaits Go |
.nodejs.org, .yarnpkg.com |
Node.js |
.alpinelinux.org, .debian.org, .ubuntu.com, .centos.org, .fedoraproject.org |
Référentiels de distribution Linux |
.cloudfront.net |
CloudFront distributions |
.google.com, .googleapis.com |
API Google |
.microsoft.com, .visualstudio.com |
Services Microsoft |
.sourceforge.net, .bitbucket.org |
Hébergement source |
.prisma.sh |
Prisma ORM |
get.helm.sh |
Gestionnaire de paquets Helm |
.terraform.io |
Registre Terraform |
buf.build |
Buf (Protobuf) |
.jitpack.io |
JitPack (packages JVM) |
.scala-sbt.org |
Échelle SBT |
.sheetjs.com |
Feuille JS |
.confluent.io |
Confluent (Kafka) |
.external-secrets.io |
Opérateur de secrets externes |
registry.npmmirror.com |
registre miroir npm |
Note
Si votre application nécessite un accès réseau à des domaines ne figurant pas sur cette liste, vous pouvez connecter votre environnement de test de vérification à un VPC. L'agent utilisera vos propres paramètres de pare-feu réseau, ce qui vous permettra de configurer l'accès à tous les services requis par votre application.
Révision des résultats de la révision du code
Chaque révision de code produit un rapport accessible sur la page Versions de l'application Web DevOps Agent. Les rapports incluent :
Recherche de catégories : violations des politiques, risques de dépendance, problèmes de contrôle d'accès et lacunes en matière de couverture des tests
Niveaux de gravité : blocage (à corriger avant la fusion), avertissement (à adresser) et information (sensibilisation uniquement)
Journal d'exécution : trace complète des étapes d'évaluation et des outils utilisés par l'agent, offrant une transparence sur la manière dont les conclusions ont été tirées
Vous pouvez également poser des questions complémentaires dans le chat de DevOps l'agent : « Pourquoi l'évaluation a-t-elle signalé le changement d'IAM à la ligne 42 ? » ou « Quels référentiels dépendent du point de terminaison d'API que j'ai modifié ? »
Intégration avec Kiro IDE et CLI
Pour utiliser les révisions de code de préparation à la publication dans Kiro, procédez comme suit :
Installez l'DevOps agent Kiro Power
depuis la place de marché Kiro Power The Power inclut des compétences qui indiquent à l'agent de codage quand il doit invoquer les évaluations de préparation des versions, après des modifications importantes du code et avant de créer un PR
Les résultats apparaissent directement dans l'IDE, et Kiro proposera de résoudre les problèmes identifiés
À partir de la CLI Kiro, vous pouvez également déclencher des révisions de manière explicite : l'agent de codage invoquera l'évaluation de l'état de préparation des versions et intégrera les résultats dans son flux de travail.
Intégrez à Claude Code
Pour utiliser les révisions de code de préparation à la publication dans Claude Code, procédez comme suit :
Installez le plugin DevOps Agent Claude Code
depuis la place de marché des plugins Claude Code Le plugin connecte Claude Code à votre espace d'agent et permet à l'agent de codage d'invoquer des évaluations de préparation des versions
Pendant le développement, Claude Code peut demander un examen des modifications en cours et traiter les résultats avant de les valider
Intégrez avec AWS Transformez la personnalisation
Pour utiliser les révisions de code de préparation à la publication dans AWS Transform Custom, procédez comme suit :
Téléchargez la compétence de révision du code de préparation à la publication des AWS DevOps agents à partir du référentiel d'exemples personnalisés AWS Transform
sur GitHub. Installez la compétence dans votre environnement AWS Transform en suivant les instructions du référentiel README.
Une fois installée, la compétence s'intègre au flux de génération de code de AWS Transform. Lorsque Transform génère ou modifie du code, la compétence invoque une évaluation de l'état de préparation des versions par rapport aux modifications proposées.
Les résultats de la revue apparaissent directement dans la sortie Transform. Si des problèmes sont identifiés, Transform peut les résoudre avant de finaliser la modification du code.
Utilisation des revues de code dans GitHub
Prérequis : GitHub référentiel connecté à votre espace agent avec les révisions automatisées activées. Pour les instructions de configuration, voir Configuration de la révision du code et des tests automatisés.
Les avis apparaissent sous forme de commentaires en ligne sur les différences de pull request, avec un commentaire de statut général
Configurer comme contrôle d'état obligatoire pour bloquer les fusions lorsque des résultats bloquants existent
Utilisation des revues de code dans GitLab
Prérequis : GitLab projet connecté à votre espace agent avec les révisions automatisées activées. Pour les instructions de configuration, voir Configuration de la révision du code et des tests automatisés.
Les avis apparaissent sous forme de commentaires en ligne sur les différences entre les demandes de fusion, avec une note globale
Configurer en tant que règle d'approbation des demandes de fusion pour exiger la résolution des résultats de blocage
Utilisation des révisions de code dans le chat de DevOps l'agent
Depuis le chat de l' DevOps agent, vous pouvez :
Demandez des révisions de l'étendue de n'importe quelle branche, commit ou référentiel
Demandez à l'agent ce qu'il sait des dépendances de votre projet : « Quelles bases de code interagissent avec le service dans le dépôt de paiements ? »
Posez des questions de suivi sur des résultats spécifiques
Demander à l'agent de générer un correctif pour un problème identifié
Afficher le graphique de connaissances sur les dépendances pour vos référentiels connectés
Garde-corps de sécurité Agentic
Les évaluations de l'état de préparation des versions incluent des barrières de sécurité intégrées qui empêchent les comportements dangereux courants des agents. Ces garde-fous sont toujours actifs pendant le processus de révision. Les comportements spécifiques en matière de couverture et d'application peuvent changer au fur et à mesure de l'évolution de la fonctionnalité. Bien que nous nous efforcions de couvrir autant de comportements dangereux courants que possible, certains comportements ne seront pas assortis de barrières de sécurité correspondantes.
Prévention de l'exposition aux informations d'identification
L'agent bloque tout appel d'outil dont l'entrée contient des modèles d'informations d'identification courants en texte clair, tels que des AWS clés, des jetons d'accès et des clés privées.
Détection de l'exfiltration de fichiers sensibles
L'agent analyse et bloque les commandes shell qui combinent l'accès à des chemins de fichiers sensibles avec des opérations réseau, empêchant ainsi les tentatives d'exfiltration de données.
Mutatif AWS blocage des opérations
L'agent bloque tout appel AWS d'API susceptible de modifier votre infrastructure. Cela empêche l'agent de révision d'apporter des modifications à votre AWS environnement pendant l'analyse. Read-only les opérations (describe, get, list) sont autorisées ; les opérations mutatives sont bloquées.
Read-only les opérations telles que describe_*get_*, et list_* sont autorisées.
Application des phases séquentielles
Les phases de révision de l'état de préparation des versions doivent être exécutées dans l'ordre. Cela garantit une évaluation systématique et approfondie et évite des évaluations incomplètes résultant d'étapes sautées.
