Révisions du code de préparation à la publication

Les révisions du code de préparation à la publication évaluent les modifications apportées au code en fonction des risques de dépendance entre référentiels, de la conformité aux normes internes et de l'exactitude du contrôle d'accès. Il effectue également des tests de vérification automatisés (il crée, exécute et teste vos modifications de code) dans un environnement de vérification géré par l' AWS DevOps agent.

Prise en main

Pour utiliser les révisions du code de préparation aux versions, effectuez les étapes de configuration suivantes.

Étape 1 : activer 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 exécute automatiquement une révision du code de préparation à chaque fois qu'une pull request ou une demande de fusion est ouverte ou mise à jour. Les résultats de l'examen apparaissent sous forme de commentaires en ligne sur le PR/MR.

• Tests de vérification automatisés : lorsqu'il est activé, DevOps l'agent crée, exécute et teste les modifications de votre code dans un environnement de vérification géré lors de la révision du code. Cela permet une validation fonctionnelle allant 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 par référentiel, ce qui vous permet d'utiliser les révisions des modifications sans tests de vérification ou vice versa.

La section inclut également :

• Rôle d'exécution (facultatif) — Choisissez le rôle IAM que l' DevOps agent assume pour exécuter les 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 aux services internes pendant les builds, tels que les registres de packages privés ou les 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, voir 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, voir Configuration de la révision du code et des tests automatisés.

Étape 2 : Configuration de l'accès VPC privé pour l'environnement de test de vérification (facultatif)

Les révisions du code de préparation à la publication peuvent effectuer des tests de vérification automatisés en créant, en exécutant et en testant les modifications apportées au 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 au sein du VPC, donnant à l'environnement de construction un accès réseau à vos services internes.

Note

L'intégration aux VPC de votre compte achemine le trafic réseau via vos itinéraires internes, conformément aux restrictions réseau en place.

Pour configurer l'accès privé au VPC pour les tests de vérification, procédez comme suit :

1. Créez une connexion privée qui cible le VPC où vos services de build internes sont accessibles. Pour obtenir des instructions, veuillez consulter Connexion à des outils hébergés en privé.

2. Ouvrez la console de l' AWS DevOps agent et accédez à votre espace agent.

3. Accédez à l'onglet Capabilities et sélectionnez votre fournisseur de pipeline (GitHub ou GitLab).

4. Dans la section Révision du code et tests automatisés, associez la connexion privée à votre fournisseur de pipeline en la sélectionnant parmi les connexions disponibles.

5. 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 sur 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.

6. 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 ainsi un accès réseau direct à vos services internes lors des builds de révision du code.

Réaliser une révision du code

Vous pouvez demander une révision du code à la demande via le chat de DevOps l'agent :

• « Passez en revue la branche feature/payments du service de paiement des dépôts pour détecter les risques liés à la publication »

• « Passez en revue le commit abc123 sur l'infrastructure de dépôt pour vérifier si vous êtes prêt à être publié »

• « 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 l'étendue 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 — Résultats spécifiques avec les emplacements de code concernés

• Recommandations — Étapes réalisables pour résoudre chaque constatation

Les révisions sont généralement terminées 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'exécutent sans intervention manuelle. Ils peuvent être déclenchés dans deux contextes :

Révisions du code lors de la génération du code

Lorsque vous utilisez le plug-in Kiro Power ou Claude Code, l'agent de codage peut demander une évaluation de l'état de préparation à la publication au fur et à mesure de la génération du code. L'examen évalue les modifications en cours par rapport à vos politiques et dépendances, en faisant ressortir 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 est averti et peut les résoudre immédiatement, en corrigeant les violations des règles, en corrigeant les politiques IAM surautorisées ou en préparant des modifications dépendantes dans d'autres référentiels.

Révisions du code dans les pull requests et les demandes de fusion

Lorsque les PR/MR révisions automatisées sont activées, l'agent examine chaque nouvelle pull request et demande de fusion dans vos référentiels connectés. Les évaluations sont déclenchées 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 intégrés 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 bloquent les fusions (vérification de statut requise) ou s'ils sont uniquement consultatifs.

Tests de vérification automatisés

Lorsqu'une évaluation des risques liés à la préparation à la publication 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 création, le stockage d'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 à la version, aux côtés des résultats relatifs aux normes, aux dépendances 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 passagère 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 application 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	Paquets Rust
.maven.org, .gradle.org	Java/Gradle colis
.nuget.org	Paquets .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

Note

Si votre application nécessite un accès réseau à des domaines ne figurant pas dans cette liste, vous pouvez connecter votre environnement de test de vérification à un VPC pour que l'agent utilise vos propres paramètres de pare-feu réseau, ce qui vous permet de configurer l'accès à tous les services dont votre application a besoin.

Révision des résultats de révision du code

Chaque révision de code produit un rapport accessible sur la page des modifications 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 dans la couverture des tests

• Niveaux de gravité : blocage (doit être corrigé avant la fusion), avertissement (doit être traité) et informatif (prise en compte uniquement)

• Journal d'exécution — La 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'avis a-t-il signalé le changement d'IAM à la ligne 42 ? » ou « Quels référentiels dépendent du point de terminaison de l'API que j'ai modifié ? »

Intégration à l'IDE et à la CLI de Kiro

Pour utiliser les révisions du code de préparation à la publication dans Kiro, procédez comme suit :

1. Installez l' DevOps agent Kiro Power depuis le Kiro Power Marketplace

2. Le pouvoir inclut des compétences qui indiquent à l'agent de codage quand invoquer des évaluations de préparation aux versions, après des modifications de code importantes et avant de créer un PR

3. 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 à la publication et intégrera les résultats dans son flux de travail.

Intégrer avec Claude Code

Pour utiliser les révisions du code de préparation à la publication dans Claude Code :

1. Installez le plugin DevOps Agent Claude Code

2. Le plugin connecte Claude Code à votre espace agent et permet à l'agent de codage d'invoquer des évaluations de préparation aux versions

3. Au cours du développement, Claude Code peut demander un examen des modifications en cours et répondre aux conclusions avant de s'engager

Intégrez avec AWS Transformez sur mesure

Pour utiliser les révisions du code de préparation à la publication dans AWS Transform Custom :

1. Téléchargez la compétence de révision du code de préparation à la publication de l' AWS DevOps agent depuis le référentiel d'échantillons personnalisés AWS Transform sur GitHub.

2. Installez la compétence dans votre environnement AWS Transform en suivant les instructions du référentiel README.

3. Une fois installée, la compétence s'intègre au flux de travail de génération de code de AWS Transform. Lorsque Transform génère ou modifie du code, la compétence invoque un examen de l'état de préparation à la publication par rapport aux modifications proposées.

4. Les résultats de l'examen 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 révisions de code dans GitHub

Conditions préalables : GitHub référentiel connecté à votre espace agent avec 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 intégrés dans les diffs de pull request, avec un commentaire sur le statut général

• Configurer comme vérification d'état obligatoire pour bloquer les fusions lorsque des résultats de blocage existent

• L'agent passe en revue tous les PR par défaut ; le filtrage des chemins et des branches est configurable dans les paramètres de votre espace agent

Utilisation des révisions de code dans GitLab

Prérequis : GitLab projet connecté à votre espace agent avec des 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 intégrés sur les différences relatives aux demandes de fusion, avec une note générale

• Configuration en tant que règle d'approbation des demandes de fusion pour exiger la résolution des problèmes de blocage

• L'agent passe en revue tous les MR par défaut ; le filtrage des chemins et des branches est configurable dans les paramètres de votre espace agent

Utilisation des révisions de code dans le chat avec les DevOps agents

Depuis le chat de l' DevOps agent, vous pouvez :

• Demandez des révisions de l'étendue d'une branche, d'un commit ou d'un référentiel

• Demandez à l'agent ce que sait l'agent au sujet des dépendances de votre projet : « Quelles bases de code interagissent avec le service dans le dépôt des 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 graphe de connaissances sur les dépendances pour vos référentiels connectés

Rambardes de sécurité Agentic

Les évaluations de l'état de préparation aux versions incluent des barrières de sécurité intégrées qui empêchent les comportements dangereux courants des agents. Ces garde-corps sont toujours actifs pendant le processus de révision. Le comportement spécifique en matière de couverture et d'application peut changer au fur et à mesure de l'évolution de la fonctionnalité. Bien que notre objectif soit de couvrir le plus grand nombre possible de comportements dangereux courants, certains comportements ne seront pas dotés de garde-corps correspondants.

Prévention de l'exposition aux informations d'identification

L'agent bloque tout appel d'outil lorsque l'entrée de l'outil contient des modèles 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 d'exfiltration de fichiers sensibles

L'agent analyse et bloque les commandes shell qui associent l'accès à des chemins de fichiers sensibles à 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 des opérations telles que describe_*get_*, et list_* sont autorisées.

Mise en œuvre par phase séquentielle

Les phases d'examen de l'état de préparation à la publication doivent être exécutées dans l'ordre. Cela garantit une évaluation systématique et approfondie et empêche les évaluations incomplètes de sauter des étapes.