Personnalisé

Qu'est-ce que AWS Transformer sur mesure ?

AWS Transform Custom utilise l'intelligence artificielle agentique pour moderniser à grande échelle les logiciels, le code, les bibliothèques et les frameworks afin de réduire la dette technique. Il gère divers scénarios, notamment les mises à niveau des versions linguistiques, les migrations d'API et de services, les mises à niveau et les migrations de framework, le refactoring du code et les transformations spécifiques à l'organisation.

Grâce à l'apprentissage continu, l'agent améliore chaque exécution et les commentaires des développeurs, en fournissant des transformations reproductibles de haute qualité sans avoir besoin d'une expertise spécialisée en automatisation.

Capacités clés

AWS Transform Custom fournit les fonctionnalités suivantes :

• Définition de transformation basée sur le langage naturel - Créez des transformations personnalisées à l'aide du langage naturel, de la documentation et d'exemples de code

• Exécution des transformations : appliquez les transformations de manière cohérente et fiable sur plusieurs bases de code

• Apprentissage continu - Améliorez automatiquement la qualité de la transformation à chaque exécution

• AWS-transformations gérées - Utilisez des transformations prêtes à l'emploi et validées pour les AWS scénarios courants

Schémas de transformation

AWS Transform Custom prend en charge divers modèles de transformation pour répondre à vos besoins de modernisation. Chaque modèle présente des caractéristiques de complexité différentes en fonction de l'ampleur et de la nature des modifications requises.

Modèle	Description	Complexité	Exemples
Migrations d'API et de services	Migration entre les versions d'API ou les services équivalents tout en conservant les fonctionnalités	Moyenne	AWS SDK v1→v2 (Java, Python, JavaScript), Boto2→Boto3, JUnit 4→5, javax→jakarta
Mises à niveau des versions linguistiques	Mise à niveau vers de nouvelles versions du même langage de programmation, adoption de nouvelles fonctionnalités et remplacement de fonctionnalités obsolètes	Low-Medium	Java 8→17, Python 3.9→3.13, 12→22, mises à niveau de version Node.js TypeScript
Améliorations du framework	Mise à niveau vers des versions plus récentes du même framework, prise en compte des modifications majeures	Moyenne	Spring Boot 2.x→3.x, React 17→18, mises à niveau angulaires, mises à niveau de Django
Migrations du framework	Migration vers des frameworks totalement différents ayant des objectifs similaires	Élevée	Angular→React, Redux→Zustand, →React Vue.js
Mises à niveau des bibliothèques et des dépendances	Mise à niveau de bibliothèques tierces vers des versions plus récentes tout en conservant le même langage et le même framework	Low-Medium	Pandas 1.x→2.x, mises à niveau, mises à niveau de bibliothèque, NumPy Hadoop/HBase/Hive mises à niveau de Lodash
Refactorisation du code et modernisation des modèles	Modernisation des modèles de code et adoption des meilleures pratiques sans modifier les fonctionnalités externes	Low-Medium	Imprimer → Cadres de journalisation, concaténation de chaînes → chaînes f, adoption des indications de type, instrumentation d'observabilité
Script et File-by-File traductions	Traduction de scripts indépendants ou de fichiers de configuration dans lesquels les fichiers sont pour la plupart autonomes	Low-Medium	AWS CDK→Terraform, Terraform→, Excel→Carnets Python, CloudFormation Bash→ PowerShell
Migrations d'architecture	Migration entre architectures matérielles ou environnements d'exécution avec un minimum de modifications de code	Medium-High	x86 →AWS Graviton (ARM), sur site → Lambda, serveur traditionnel → conteneurs
Language-to-Language Migrations	Traduction de bases de code d'un langage de programmation à un autre	Très élevé	Java→Python, →, C→Rust, JavaScript TypeScript Python→Go
Personnalisation et Organization-Specific transformations	Exigences organisationnelles uniques et besoins de modernisation spécialisés	Varie	Migrations de bibliothèques internes personnalisées, normes de codage spécifiques à l'organisation, migrations de frameworks propriétaires

Note

Pour les COBOL/mainframe langues, utilisez AWS Transform for Mainframe. Pour les mises à niveau de .NET Framework vers .NET Core, pensez à AWS Transform pour Windows. Pour les migrations vers VMware AWS, pensez à AWS Transform for VMware.

Comment ? AWS Transformez des œuvres personnalisées

AWS La transformation personnalisée est généralement utilisée dans les projets à grande échelle où plusieurs bases de code ou modules sont transformés. Les équipes suivent généralement un flux de travail en quatre phases :

Définir la transformation : fournissez des instructions en langage naturel, de la documentation et des exemples de code à l'agent, qui génère une définition de transformation initiale. Cette définition peut être affinée de manière itérative par le biais du chat ou de modifications directes. Cette phase peut être ignorée lors de l'utilisation de transformations AWS gérées par -managed.

Pilotez ou Proof-of-Concept - Testez la transformation sur des exemples de bases de code et affinez-la en fonction des résultats. Cette phase de validation permet d'estimer le coût et les efforts liés à la transformation complète. L'apprentissage continu améliore la qualité au cours de cette phase.

Exécution échelonnée : configurez une exécution en masse automatisée à l'aide de la CLI, les développeurs passant en revue et validant les résultats. Surveillez les progrès à l'aide de l'application Web et suivez les transformations dans plusieurs référentiels.

Surveillance et révision : l'apprentissage continu améliore automatiquement la qualité de la transformation. Passez en revue les leçons tirées des éditions précédentes pour vous assurer qu'elles répondent aux normes de qualité, et archivez celles qui ne sont pas utiles.

Comprendre les concepts clés

Cette section explique les concepts clés relatifs à l'utilisation de AWS Transform custom.

Définitions de transformation

Une définition de transformation contient les instructions et les connaissances nécessaires pour effectuer une transformation de code spécifique. Elle est représentée comme une compétence et comprend :

• SKILL.md(obligatoire) - Instructions en Markdown avec matière (nameet description champs) YAML contenant la logique de transformation de base et les instructions d'exécution

• references/dossier (facultatif) - Documentation chargée selon les besoins lors de l'exécution de la transformation

• scripts/dossier (facultatif) - Scripts que la transformation télécharge et exécute pendant l'exécution

AWS Transform CLI télécharge automatiquement les définitions de transformation dans le répertoire actuel lorsque cela est nécessaire pour l'exécution, l'inspection ou la modification.

Important

Lors de la publication d'une transformation, le répertoire doit contenir uniquement SKILL.md et éventuellement le references/ dossier, le scripts/ dossier ou les deux. Aucun autre fichier ou sous-répertoire n'est autorisé.

Note

Les versions 2.0 et ultérieures de la CLI utilisent le format skills. Les définitions de transformation existantes sont automatiquement gérées par la CLI.

Catégories de définition de transformation

Une définition de transformation peut comporter une catégorie indiquant comment elle est utilisée :

• analysis— Lit le code et rapporte les résultats. La modernisation continue exécute ces définitions de transformation dans le cadre d'une analyse personnalisée.

• remediation— Modifie le code. La modernisation continue utilise ces définitions de transformation pour corriger les résultats.

Définissez la catégorie avec l'--categoryoption atx custom def publish ou atx custom def save-draft :

atx custom def publish -n <transformation-name> --description "Description" --sd <directory> --category analysis
atx custom def publish -n <transformation-name> --description "Description" --sd <directory> --category remediation
atx custom def list    # The Category column shows each transformation definition's category

AWS Transform utilise la catégorie pour décider où une définition de transformation peut être utilisée.

Utilisation	Définitions de transformation autorisées
Analyse personnalisée (--type custom)	Vos propres définitions de transformation avec la analysis catégorie
Assainissement avec --transformation-name	Vos propres définitions de transformation avec la remediation catégorie, ou transformations AWS gérées

Avant de soumettre une analyse, un calendrier ou une correction personnalisés, AWS Transform vérifie la catégorie de la définition de transformation.

Pour modifier la catégorie d'une définition de transformation, publiez-la à nouveau avec une --category valeur différente. Si vous publiez une nouvelle version sans--category, la nouvelle version conserve la catégorie de la version précédente.

Pour savoir comment exécuter une définition de analysis transformation, consultezAnalyse personnalisée.

Note

Une catégorie est différente d'une étiquette de ressource. Pour gérer les balises de ressources, voirCommandes de balises.

Rédiger une définition de transformation à des fins d'analyse

Pour obtenir des résultats utiles, rédigez la définition de la transformation de manière à décrire ce qu'il faut rechercher, comment classer chaque problème et ce qu'il ne faut pas faire. Nous recommandons les sections suivantes dansSKILL.md.

Section	Ce qu'il faut inclure
Introduction	Une ou deux phrases indiquant les résultats de l'analyse. Indiquez qu'il est en lecture seule et qu'il ne doit modifier aucun fichier.
Critères d'entrée	Lorsque l'analyse s'applique, par exemple « Le référentiel contient un build.gradle fichier pom.xml or ».
Scope	Les fichiers et les répertoires à inspecter, ainsi que ceux à ignorer, tels que les résultats de compilation et les dépendances fournies par les fournisseurs.
Ce qu'il faut signaler	Les modèles ou conditions spécifiques considérés comme un problème. Demandez un résultat par problème, avec le chemin du fichier et le numéro de ligne.
Catégories	Un petit ensemble fixe de valeurs de catégories, indiquant quels problèmes appartiennent à chacune d'entre elles.
Critères de sévérité	Qu'est-ce qui pose problème highmedium, oulow.
Critères de sortie	Comment l'agent sait que c'est fait : chaque fichier concerné a été inspecté, chaque résultat est associé à un fichier, à une catégorie et à une gravité, et aucun fichier n'a été modifié. Indiquez également ce qu'il faut signaler lorsque rien n'est trouvé.

L'exemple suivant trouve des projets Java qui ciblent toujours une version de Java antérieure à la version 17.

---
name: java-version-detector
description: Report where a repository still targets a Java version earlier than 17, in build files, Dockerfiles, toolchain files, and CI workflows. Analysis only - no code is modified.
---

# Java Version Detector

Find where the repository targets a Java version earlier than Java 17. This is a
read-only analysis: report findings, and do not modify any files.

## Entry Criteria

The repository contains a Java build file (`pom.xml`, `build.gradle`,
`build.gradle.kts`, or `gradle.properties`), or a file that selects a JDK
(`.java-version`, `.tool-versions`, `.sdkmanrc`, a `Dockerfile`, or a file under
`.github/workflows/`).

## Scope

- Inspect build files, toolchain files, Dockerfiles, and CI workflow files.
- Skip build output (`build/`, `target/`) and vendored dependencies.

## What to Report

Report one finding for each place that selects a Java version earlier than 17:

1. A compile target, such as `maven.compiler.source`, `maven.compiler.release`,
   `java.version`, `sourceCompatibility`, or a Gradle toolchain `languageVersion`.
2. A Dockerfile base image that ships a JDK or JRE earlier than 17, such as
   `openjdk:8` or `amazoncorretto:11`.
3. A CI job or toolchain file that selects a JDK earlier than 17.

For each finding, include the file path, the line number, and the version you found.

## Categories

- `outdated-compile-target` - a build file compiles for an old Java version
- `outdated-runtime-image` - a Dockerfile uses an old JDK or JRE image
- `outdated-ci-jdk` - a CI workflow or toolchain file selects an old JDK

## Severity Criteria

- **high** - the project compiles for Java 8 or earlier
- **medium** - the project compiles for Java 9 through 16
- **low** - only the runtime image or CI uses an old JDK, and the compile target is 17 or later

## Exit Criteria

1. Every in-scope file has been inspected.
2. Every finding has a file path, line number, category, and severity from the lists above.
3. No file in the repository has been modified.
4. If nothing is found, state that the repository targets Java 17 or later.

Lorsque cette définition de transformation s'applique à un projet dont les pom.xml ensembles sont définis<source>1.8</source>, elle produit une constatation de high gravité dans la outdated-compile-target catégorie, avec AWS/java-version-upgrade comme solution.

Conseils pour rédiger des définitions de transformation d'analyse

• Gardez-le en lecture seule. Indiquez explicitement que l'analyse ne doit pas modifier les fichiers. La résolution des problèmes est une tâche de remédiation.

• Soyez précis quant à ce qui constitue un problème. Nommez les fichiers, les paramètres et les modèles à rechercher. Des instructions vagues produisent des résultats incohérents.

• Demandez une seule constatation par problème. Chaque résultat doit pointer vers un fichier et une ligne spécifiques afin qu'il puisse être examiné et corrigé individuellement.

• Définissez la gravité et les catégories dans la définition de la transformation. L'agent utilise vos critères pour classer chaque résultat.

• Gardez la lunette focalisée. Une analyse personnalisée indique uniquement ce que décrit sa définition de transformation. Pour détecter de nombreux types de problèmes, rédigez des définitions de transformation distinctes ou utilisez les types d'analyse intégrés.

• Dites ce qu'il faut faire si rien n'est trouvé. Un référentiel qui ne présente aucun problème correctement ne produit aucun résultat.

• Incluez les instructions de recherche dans la définition de la transformation. Si vous transmettez la configuration avec -g ou --configuration lorsque vous exécutez l'analyse, AWS Transform utilise votre configuration au lieu de ses instructions par défaut. Le fait de conserver la section « Ce qu'il faut signaler » SKILL.md permet à la définition de la transformation de produire des résultats dans les deux cas.

Testez la définition de transformation sur un référentiel dont vous savez qu'il contient le problème avant de le publier. Enregistrez-le sous forme de brouillon avecatx custom def save-draft, ou exécutez-le localement avec atx ct analysis run (voirAnalyse personnalisée).

Registre des transformations

Le registre des transformations est le référentiel centralisé de votre AWS compte pour le stockage et la gestion des définitions de transformation. Les transformations du registre peuvent être les suivantes :

• Listé en utilisant atx custom def list

• Exécuté sur plusieurs bases de code

• Partagé avec d'autres utilisateurs de votre AWS compte

• Version-controlled

Important

Les définitions de transformation sont spécifiques au compte. Si vous souhaitez utiliser une transformation dans un autre AWS compte, vous devez la publier séparément dans ce compte.

Transformations préliminaires et transformations publiées

AWS Transform custom prend en charge deux états pour les transformations dans le registre :

Les ébauches de transformations sont des définitions de transformation en cours ou non testées. Ils sont enregistrés sous forme de versions spécifiques et peuvent être récupérés, mis à jour et exécutés par les utilisateurs se référant à cette version spécifique. Les brouillons sont utiles pour le développement itératif, les tests et le perfectionnement avant que la transformation ne soit prête à être partagée avec votre équipe. Les brouillons sont également associés à une conversation spécifique. Si vous redémarrez la CLI, vous pouvez l'utiliser atx --conversation-id {id} pour restaurer une version précédente.

Les transformations publiées sont disponibles dans le registre des transformations de votre compte pour être exécutées par d'autres utilisateurs disposant des autorisations IAM requises. Les transformations publiées peuvent être découvertes à l'aide deatx custom def list.

Le flux de travail typique est le suivant :

1. Créez une transformation au niveau local

2. Enregistrer en tant que brouillon pour les tests (atx custom def save-draft)

3. Affiner et valider

4. Publiez pour partager avec votre équipe (atx custom def publish)

Vous pouvez également publier une transformation directement sans l'enregistrer en tant que brouillon.

Références et leçons

AWS Transform custom utilise deux types de connaissances pour améliorer la qualité de la transformation :

Les références sont de la documentation fournie par l'utilisateur et stockée dans le references/ dossier d'une définition de transformation. Les références ne prennent en charge que les fichiers texte (maximum 10 Mo au total pour tous les fichiers) et contiennent généralement de la documentation, des spécifications d'API, des guides de migration et des exemples de code. Les références sont chargées selon les besoins lors de l'exécution de la transformation. Vous ajoutez des références lors de la création ou de la mise à jour d'une définition de transformation en mode interactif.

Les leçons sont automatiquement extraites des exécutions précédentes d'une transformation. Le système d'apprentissage continu les génère à partir des trajectoires d'exécution, des commentaires des développeurs et des corrections de code rencontrées lors des transformations. Il regroupe les leçons connexes en catégories afin que vous puissiez les consulter ensemble. Contrairement aux références, que vous fournissez dès le départ, les leçons s'accumulent au fil du temps à mesure que vous exécutez la transformation sur différentes bases de code, et le système les applique automatiquement pour améliorer les exécutions futures. Vous révisez et gérez les leçons de manière interactive avecatx custom def learnings.

Commandes de génération et de validation

La commande de génération ou de validation est un paramètre facultatif qui indique comment valider votre code pendant le processus de transformation. Cette commande est exécutée à différents moments de la transformation pour garantir l'intégrité du code.

Il est très important de fournir une commande qui valide les résultats et renvoie des problèmes en cas d'échec de la validation pour améliorer la qualité de la transformation grâce à un apprentissage continu. Si aucune compilation ou validation n'est nécessaire, omettez de le saisir.

Pour des exemples et des instructions détaillées, voir Commandes de génération et de validation dans la section Workflows.

Apprentissage continu

L'apprentissage continu est le système qui capture automatiquement les commentaires issus de chaque exécution de transformation et améliore la qualité de la transformation au fil du temps. Le système recueille des informations par le biais de :

• Feedback explicite - Commentaires et corrections de code fournis en mode interactif

• Observations implicites - Problèmes rencontrés par l'agent lors de la transformation et du débogage du code

Le système d'apprentissage continu traite ces informations pour créer des leçons qu'il ajoute à la définition de la transformation afin d'améliorer les transformations futures. Le système exécute le processus d'apprentissage automatiquement une fois les transformations terminées, sans intervention supplémentaire de votre part.

Important

Les leçons sont spécifiques à la transformation et ne sont pas partagées entre les différentes transformations ou les différents comptes clients.

Gérer les leçons

Le système génère des leçons automatiquement, mais vous gardez le contrôle de celles qu'il appliquera aux futures courses. La atx custom def learnings commande ouvre une session de terminal interactive pour examiner et organiser les leçons qu'une transformation a accumulées.

Au cours de cette session, vous pouvez :

• Parcourez les leçons regroupées en catégories et découvrez le nombre de leçons actives que contient chaque catégorie.

• Ouvrez une leçon pour en lire tous les détails, y compris le corps de la leçon, son impact et le nombre de sessions précédentes qui l'ont consultée.

• Archivez une leçon pour empêcher le système de l'appliquer à de futures exécutions, et restaurez-la ultérieurement si nécessaire.

• Supprimez définitivement une leçon archivée qui n'est plus utile.

Pour obtenir des instructions détaillées, consultez Apprentissage continu.

Client-Side Compétences

Client-side les compétences sont des capacités supplémentaires qui étendent l'agent lors des exécutions de transformation. Contrairement aux définitions de transformation qui définissent la transformation à effectuer, les compétences côté client fournissent des outils, des scripts et des instructions supplémentaires que l'agent peut utiliser parallèlement à ses fonctionnalités intégrées lors de toute transformation.

Client-side les compétences sont découvertes à partir de répertoires au niveau du projet et au niveau de l'utilisateur. Placez les compétences au niveau du projet lorsqu'elles appliquent des normes spécifiques à un référentiel, et au niveau de l'utilisateur lorsqu'elles s'appliquent à tous vos projets. Project-level les compétences ne sont disponibles que lorsqu'un chemin de dépôt de code est fourni. Pour une configuration et une utilisation détaillées, voirClient-Side Compétences.

Présentation des commandes de transformation personnalisées

Voici quelques-unes des commandes que vous pouvez utiliser pour les transformations personnalisées. La liste complète des commandes se trouve dans la référence des commandes AWS Transform custom transformations.

• atx custom

  • Exécute une expérience interactive de transformation personnalisée, permettant la création, la découverte, l'exécution et le raffinement des transformations.

  • Il s'agit de la commande par défaut pouratx.

  • --trust-all-tools(-t) est facultatif et autorise implicitement toutes les demandes d'outils demandées par l'agent. À utiliser avec prudence, en particulier dans les environnements de production. Vous pouvez configurer l'approbation des outils pour des outils et des commandes spécifiques à l'aide du fichier de paramètres de confiance.

• atx custom --help | atx custom -h

  • Affiche le menu d'aide.

  • Chaque commande inclut également un menu d'aide, par exemple,atx custom def exec --help.

• atx --version | atx -v

  • Affiche la version.

  • Le numéro de version change à chaque publication.

• atx custom def list

  • Imprime la liste des transformations disponibles dans le registre des transformations.

• atx custom def exec

  • Exécute une transformation

• atx custom def learnings

  • Ouvre une session interactive pour afficher et gérer les leçons apprises lors des exécutions précédentes lors d'une transformation.

• atx mcp

  • Utilisé pour gérer les configurations des serveurs MCP