Personalizzato

Che cos'è AWS Trasformazione personalizzata?

AWS Transform custom utilizza l'intelligenza artificiale agentica per eseguire la modernizzazione su larga scala di software, codice, librerie e framework per ridurre il debito tecnico. Gestisce diversi scenari, tra cui aggiornamenti delle versioni linguistiche, migrazioni di API e servizi, aggiornamenti e migrazioni del framework, refactoring del codice e trasformazioni specifiche dell'organizzazione.

Attraverso l'apprendimento continuo, l'agente migliora sulla base di ogni esecuzione e feedback degli sviluppatori, offrendo trasformazioni ripetibili e di alta qualità senza richiedere competenze specializzate in automazione.

Funzionalità chiave

AWS Transform custom offre le seguenti funzionalità:

• Definizione di trasformazione basata sul linguaggio naturale: crea trasformazioni personalizzate utilizzando linguaggio naturale, documentazione ed esempi di codice

• Esecuzione della trasformazione: applica le trasformazioni in modo coerente e affidabile su più basi di codice

• Apprendimento continuo: migliora automaticamente la qualità della trasformazione a partire da ogni esecuzione

• AWS-trasformazioni gestite - Utilizza trasformazioni pronte all'uso e controllate per scenari comuni AWS

Modelli di trasformazione

AWS Transform custom supporta diversi modelli di trasformazione per soddisfare le vostre esigenze di modernizzazione. Ogni modello presenta caratteristiche di complessità diverse in base all'ambito e alla natura delle modifiche richieste.

Pattern	Description	Complessità	Esempi
Migrazioni di API e servizi	Migrazione tra versioni API o servizi equivalenti mantenendo la funzionalità	Media	AWS SDK v1 → v2 (Java, Python,), Boto2 → Boto3, JUnit 4 → 5, javax → JavaScript jakarta
Aggiornamenti della versione linguistica	Aggiornamento a versioni più recenti dello stesso linguaggio di programmazione, adozione di nuove funzionalità e sostituzione di funzionalità obsolete	Low-Medium	Java 8→17, Python 3.9→3.13, 12→22, aggiornamenti di versione Node.js TypeScript
Aggiornamenti del framework	Aggiornamento a versioni più recenti dello stesso framework, risoluzione delle modifiche più importanti	Media	Spring Boot 2.x→3.x, React 17→18, aggiornamenti Angular, aggiornamenti Django
Migrazioni del framework	Migrazione verso framework completamente diversi che hanno scopi simili	Elevata	Angular→React, Redux→Zustand, →React Vue.js
Aggiornamenti della libreria e delle dipendenze	Aggiornamento delle librerie di terze parti a versioni più recenti mantenendo lo stesso linguaggio e lo stesso framework	Low-Medium	Pandas 1.x→2.x, aggiornamenti, aggiornamenti delle librerie, aggiornamenti Lodash NumPy Hadoop/HBase/Hive
Rifattorizzazione del codice e modernizzazione dei pattern	Modernizzazione dei modelli di codice e adozione delle migliori pratiche senza modificare le funzionalità esterne	Low-Medium	Stampa → Framework di registrazione, concatenazione di stringhe → stringhe f, adozione di suggerimenti di tipo, strumentazione di osservabilità
File-by-File Script e traduzioni	Traduzione di script o file di configurazione indipendenti in cui i file sono per lo più autonomi	Low-Medium	AWS CDK→Terraform, Terraform→, Excel→Quaderni PythonCloudFormation, Bash→ PowerShell
Migrazioni dell'architettura	Migrazione tra architetture hardware o ambienti di runtime con modifiche minime al codice	Medium-High	x86 →AWS Graviton (ARM), locale → Lambda, server tradizionale → contenitori
Language-to-Language Migrazioni	Traduzione di codebase da un linguaggio di programmazione a un altro	Molto alto	Java→Python, →, C→Rust, JavaScript Python→Vai TypeScript
Personalizzazione Organization-Specific e trasformazioni	Requisiti organizzativi unici ed esigenze di modernizzazione specializzate	Può variare	Migrazioni personalizzate di librerie interne, standard di codifica specifici dell'organizzazione, migrazioni di framework proprietari

Nota

Per le lingue, usa Transform for COBOL/mainframe Mainframe. AWS Per gli aggiornamenti di.NET Framework a.NET Core, prendi in considerazione AWS Transform for Windows. Per le migrazioni da VMware a AWS, prendi in considerazione AWS Transform for VMware.

In che modo AWS Transform Custom Works

AWS Transform custom viene solitamente utilizzato in progetti su larga scala in cui vengono trasformate più basi di codice o moduli. I team in genere seguono un flusso di lavoro in quattro fasi:

Definisci la trasformazione: fornisci all'agente istruzioni, documentazione ed esempi di codice in linguaggio naturale, che genera una definizione iniziale di trasformazione. Questa definizione può essere perfezionata in modo iterativo tramite chat o modifiche dirette. Questa fase può essere saltata quando si utilizzano AWS trasformazioni gestite.

Pilota o Proof-of-Concept: testa la trasformazione su basi di codice di esempio e perfezionala in base ai risultati. Questa fase di convalida aiuta a stimare i costi e gli sforzi della trasformazione completa. L'apprendimento continuo migliora la qualità durante questa fase.

Esecuzione scalata: configura l'esecuzione di massa automatizzata utilizzando la CLI, con gli sviluppatori che esaminano e convalidano i risultati. Monitora i progressi utilizzando l'applicazione web e monitora le trasformazioni su più repository.

Monitoraggio e revisione: l'apprendimento continuo migliora automaticamente la qualità della trasformazione. Rivedi le lezioni estratte dalle esecuzioni precedenti per assicurarti che soddisfino gli standard di qualità e archivia quelle che non sono utili.

Comprensione dei concetti chiave di

Questa sezione spiega i concetti chiave per lavorare con AWS Transform custom.

Definizioni di trasformazione

Una definizione di trasformazione contiene le istruzioni e le conoscenze necessarie per eseguire una trasformazione specifica del codice. È rappresentata come un'abilità e consiste in:

• SKILL.md(obbligatorio) - Istruzioni in Markdown con frontespizio (namee description campi) YAML che contiene la logica di trasformazione di base e le istruzioni di esecuzione

• references/folder (opzionale) - Documentazione caricata secondo necessità durante l'esecuzione della trasformazione

• scripts/folder (opzionale): script che la trasformazione scarica ed esegue durante l'esecuzione

AWS Transform CLI scarica automaticamente le definizioni di trasformazione nella directory corrente quando necessario per l'esecuzione, l'ispezione o la modifica.

Importante

Quando si pubblica una trasformazione, la directory deve contenere solo SKILL.md e facoltativamente la references/ cartella, la scripts/ cartella o entrambe. Non sono consentiti altri file o sottodirectory.

Nota

La versione CLI 2.0 e successive utilizza il formato skills. Le definizioni di trasformazione esistenti vengono gestite automaticamente dalla CLI.

Categorie di definizione delle trasformazioni

Una definizione di trasformazione può avere una categoria che indica come viene utilizzata:

• analysis— Legge il codice e riporta i risultati. La modernizzazione continua esegue queste definizioni di trasformazione come analisi personalizzata.

• remediation— Modifica il codice. La modernizzazione continua utilizza queste definizioni di trasformazione per correggere i risultati.

Imposta la categoria con l'--categoryopzione o: atx custom def publish 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 utilizza la categoria per decidere dove utilizzare una definizione di trasformazione.

Utilizzo	Definizioni di trasformazione consentite
Analisi personalizzata (--type custom)	Definizioni di trasformazione personalizzate con la analysis categoria
Riparazione con --transformation-name	Definizioni di trasformazione personalizzate con la remediation categoria o trasformazioni AWS gestite

Prima di inviare un'analisi, una pianificazione o una correzione personalizzate, AWS Transform controlla la categoria della definizione di trasformazione.

Per modificare la categoria di una definizione di trasformazione, pubblicala nuovamente con un valore diverso--category. Se pubblicate una nuova versione senza--category, la nuova versione mantiene la categoria della versione precedente.

Per informazioni su come eseguire una definizione di analysis trasformazione, consultaAnalisi personalizzata.

Nota

Una categoria è diversa da un tag di risorsa. Per gestire i tag delle risorse, vediComandi per tag.

Scrivi una definizione di trasformazione per l'analisi

Per ottenere risultati utili, scrivi la definizione di trasformazione in modo che descriva cosa cercare, come classificare ogni problema e cosa non fare. Consigliamo le seguenti sezioni inSKILL.md.

Sezione	Cosa includere
Introduzione	Una o due frasi che indicano i risultati dell'analisi. Indica che è di sola lettura e non deve modificare alcun file.
Criteri di ingresso	Quando si applica l'analisi, ad esempio «Il repository contiene un build.gradle file pom.xml or».
Scope	I file e le directory da esaminare e quelli da ignorare, ad esempio l'output della build e le dipendenze dei fornitori.
Cosa segnalare	I modelli o le condizioni specifici che costituiscono un problema. Richiedi un risultato per problema, indicando il percorso del file e il numero di riga.
Categories	Un piccolo insieme fisso di valori di categoria e quali problemi rientrano in ciascuna di esse.
Criteri di gravità	Cosa crea un problema highmedium, olow.
Criteri di uscita	In che modo l'agente sa di cosa si tratta: ogni file pertinente è stato ispezionato, ogni risultato ha un file, una categoria e un livello di gravità e nessun file è stato modificato. Indica anche cosa segnalare quando non viene trovato nulla.

L'esempio seguente trova progetti Java che hanno ancora come target una versione Java precedente alla 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.

Quando questa definizione di trasformazione viene eseguita su un progetto i cui pom.xml set vengono generati<source>1.8</source>, viene generata una rilevazione della high gravità outdated-compile-target nella categoria, con AWS/java-version-upgrade come correzione.

Suggerimenti per scrivere definizioni di analisi e trasformazione

• Mantienilo di sola lettura. Dichiara esplicitamente che l'analisi non deve modificare i file. Risolvere i problemi è il compito di una soluzione.

• Sii specifico su ciò che viene considerato un problema. Assegna un nome ai file, alle impostazioni e ai modelli da cercare. Istruzioni vaghe producono risultati incoerenti.

• Richiedi un risultato per problema. Ogni risultato deve fare riferimento a un file e a una riga specifici in modo da poter essere esaminato e corretto individualmente.

• Definisci la gravità e le categorie nella definizione della trasformazione. L'agente utilizza i tuoi criteri per classificare ogni risultato.

• Mantieni il mirino concentrato. Un'analisi personalizzata riporta solo ciò che descrive la definizione di trasformazione. Per trovare molti tipi di problemi, scrivete definizioni di trasformazione separate o utilizzate i tipi di analisi incorporati.

• Dite cosa fare quando non viene trovato nulla. Un repository che non presenta problemi produce correttamente zero risultati.

• Includi le istruzioni di ricerca nella definizione di trasformazione. Se si passa la configurazione con -g o --configuration durante l'esecuzione dell'analisi, AWS Transform utilizza la configurazione anziché le istruzioni predefinite. Mantenendo attiva la sezione «Cosa segnalare», la definizione di trasformazione produce risultati in SKILL.md entrambi i casi.

Prova la definizione di trasformazione su un repository che sai contiene il problema prima di pubblicarlo. Salvala come bozza con atx custom def save-draft o eseguila localmente con atx ct analysis run (vediAnalisi personalizzata).

Registro delle trasformazioni

Il registro delle trasformazioni è l'archivio centralizzato del tuo AWS account per l'archiviazione e la gestione delle definizioni di trasformazione. Le trasformazioni nel registro possono essere:

• Elencato utilizzando atx custom def list

• Eseguito su più basi di codice

• Condiviso con altri utenti del tuo account AWS

• Version-controlled

Importante

Le definizioni di trasformazione sono specifiche dell'account. Se desideri utilizzare una trasformazione in un AWS account diverso, devi pubblicarla separatamente in quell'account.

Bozza e trasformazioni pubblicate

AWS Transform custom supporta due stati per le trasformazioni nel registro:

Le bozze di trasformazione sono definizioni di trasformazione in corso o non testate. Vengono salvate come versioni specifiche e possono essere recuperate, aggiornate ed eseguite dagli utenti che fanno riferimento a quella versione specifica. Le bozze sono utili per lo sviluppo, il test e il perfezionamento iterativi prima che la trasformazione sia pronta per essere condivisa con il team. Le bozze sono anche associate a conversazioni specifiche. Se riavvii la CLI, puoi utilizzarla atx --conversation-id {id} per ripristinarne una precedente.

Le trasformazioni pubblicate sono disponibili nel registro delle trasformazioni del tuo account per essere eseguite da altri utenti con le autorizzazioni IAM richieste. Le trasformazioni pubblicate possono essere scoperte utilizzando. atx custom def list

Il flusso di lavoro tipico è:

1. Creare una trasformazione a livello locale

2. Salva come bozza per il test (atx custom def save-draft)

3. Perfeziona e convalida

4. Pubblica per condividerlo con il tuo team () atx custom def publish

Puoi anche pubblicare una trasformazione direttamente senza salvarla come bozza.

Riferimenti vs. lezioni

AWS Transform custom utilizza due tipi di conoscenze per migliorare la qualità della trasformazione:

I riferimenti sono documentazione fornita dall'utente memorizzata nella references/ cartella di una definizione di trasformazione. I riferimenti supportano solo file di testo (massimo 10 MB in totale per tutti i file) e di solito contengono documentazione, specifiche API, guide alla migrazione ed esempi di codice. I riferimenti vengono caricati secondo necessità durante l'esecuzione della trasformazione. I riferimenti vengono aggiunti durante la creazione o l'aggiornamento di una definizione di trasformazione in modalità interattiva.

Le lezioni vengono estratte automaticamente dalle esecuzioni precedenti di una trasformazione. Il sistema di apprendimento continuo le genera sulla base delle traiettorie di esecuzione, del feedback degli sviluppatori e delle correzioni di codice riscontrate durante le trasformazioni. Raggruppa le lezioni correlate in categorie in modo da poterle rivedere insieme. A differenza dei riferimenti, che vengono forniti in anticipo, le lezioni si accumulano nel tempo man mano che si esegue la trasformazione su diverse basi di codice e il sistema le applica automaticamente per migliorare le esecuzioni future. Puoi rivedere e gestire le lezioni in modo interattivo con. atx custom def learnings

Comandi di creazione e convalida

Il comando build o validation è un parametro opzionale che specifica come convalidare il codice durante il processo di trasformazione. Questo comando viene eseguito in vari punti durante la trasformazione per garantire l'integrità del codice.

Fornire un comando che convalidi i risultati e restituisca problemi se la convalida fallisce è molto importante per migliorare la qualità della trasformazione attraverso l'apprendimento continuo. Se non è necessaria alcuna compilazione o convalida, omettila dal tuo input.

Per esempi e linee guida dettagliate, consulta Comandi di compilazione e convalida nella sezione Flussi di lavoro.

Apprendimento continuo

L'apprendimento continuo è il sistema che acquisisce automaticamente il feedback da ogni esecuzione di trasformazione e migliora la qualità della trasformazione nel tempo. Il sistema raccoglie informazioni tramite:

• Feedback esplicito: commenti e correzioni di codice forniti in modalità interattiva

• Osservazioni implicite: problemi riscontrati dall'agente durante la trasformazione e il debug del codice

Il sistema di apprendimento continuo elabora queste informazioni per creare lezioni da aggiungere alla definizione di trasformazione per migliorare le trasformazioni future. Il sistema esegue automaticamente il processo di apprendimento dopo il completamento delle trasformazioni, senza richiedere alcun input aggiuntivo da parte dell'utente.

Importante

Le lezioni sono specifiche della trasformazione e non vengono condivise tra diverse trasformazioni o diversi account cliente.

Gestione delle lezioni

Il sistema genera automaticamente le lezioni, ma sei tu a decidere quali applicare alle sessioni future. Il atx custom def learnings comando apre una sessione terminale interattiva per la revisione e la cura delle lezioni accumulate durante la trasformazione.

In questa sessione, puoi:

• Sfoglia le lezioni raggruppate in categorie e scopri quante lezioni attive contiene ciascuna categoria.

• Apri una lezione per leggerne tutti i dettagli, tra cui il corpo della lezione, il suo impatto e quante sessioni precedenti l'hai consultata.

• Archivia una lezione per impedire al sistema di applicarla a esecuzioni future e ripristinala in un secondo momento, se necessario.

• Elimina definitivamente una lezione archiviata che non è più utile.

Per istruzioni dettagliate, consulta Apprendimento continuo.

Client-Side Competenze

Client-side le competenze sono funzionalità aggiuntive che estendono l'agente durante le esecuzioni di trasformazione. A differenza delle definizioni di trasformazione che definiscono la trasformazione da eseguire, le competenze lato client forniscono strumenti, script e istruzioni supplementari che l'agente può utilizzare insieme alle funzionalità integrate durante qualsiasi trasformazione.

Client-side le competenze vengono rilevate nelle directory a livello di progetto e a livello di utente. Posiziona le competenze a livello di progetto quando applicano gli standard specifici di un repository e a livello di utente quando si applicano a tutti i tuoi progetti. Project-level le competenze sono disponibili solo quando viene fornito un percorso di archiviazione del codice. Per la configurazione e l'utilizzo dettagliati, vedereClient-Side Competenze.

Introduzione ai comandi di trasformazione personalizzati

Di seguito sono riportati alcuni comandi che è possibile utilizzare con le trasformazioni personalizzate. L'elenco completo dei comandi si trova nel riferimento ai comandi AWS Transform custom transformations.

• atx custom

  • Esegue un'esperienza interattiva di trasformazione personalizzata, che consente la creazione, l'individuazione, l'esecuzione e il perfezionamento delle trasformazioni.

  • Questo è il comando predefinito per. atx

  • --trust-all-tools(-t) è facoltativo e consente implicitamente tutte le richieste di strumenti richieste dall'agente. Usare con cautela soprattutto negli ambienti di produzione. È possibile configurare l'attendibilità degli strumenti per strumenti e comandi specifici utilizzando il file delle impostazioni di attendibilità.

• atx custom --help | atx custom -h

  • Mostra il menu di aiuto.

  • Ogni comando include anche un menu di aiuto, ad esempioatx custom def exec --help.

• atx --version | atx -v

  • Mostra la versione.

  • Il numero di versione cambia con ogni versione.

• atx custom def list

  • Stampa l'elenco delle trasformazioni disponibili nel registro delle trasformazioni.

• atx custom def exec

  • Esegue una trasformazione

• atx custom def learnings

  • Apre una sessione interattiva per visualizzare e gestire le lezioni apprese da una trasformazione nelle esecuzioni precedenti

• atx mcp

  • Utilizzato per gestire le configurazioni del server MCP