Benutzerdefiniert

Was ist AWS Benutzerdefiniert transformieren?

AWS Transform Custom verwendet agentische KI, um Software, Code, Bibliotheken und Frameworks umfassend zu modernisieren und so die technische Verschuldung zu reduzieren. Es behandelt verschiedene Szenarien, darunter Upgrades von Sprachversionen, API- und Servicemigrationen, Framework-Upgrades und -Migrationen, Code-Refactoring und organisationsspezifische Transformationen.

Durch kontinuierliches Lernen verbessert sich der Agent anhand jeder Ausführung und des Feedbacks der Entwickler und liefert qualitativ hochwertige, wiederholbare Transformationen, ohne dass spezielle Automatisierungskenntnisse erforderlich sind.

Die wichtigsten Funktionen

AWS Transform custom bietet die folgenden Funktionen:

• Definition einer auf natürlicher Sprache basierenden Transformation — Erstellen Sie benutzerdefinierte Transformationen mithilfe natürlicher Sprache, Dokumentation und Codebeispielen

• Ausführung der Transformation — Wenden Sie Transformationen konsistent und zuverlässig auf mehrere Codebasen an

• Kontinuierliches Lernen — Verbessern Sie automatisch die Transformationsqualität bei jeder Ausführung

• AWS-verwaltete Transformationen — Verwenden Sie gebrauchsfertige, AWS geprüfte Transformationen für gängige Szenarien

Transformationsmuster

AWS Transform Custom unterstützt verschiedene Transformationsmuster, um Ihren Modernisierungsanforderungen gerecht zu werden. Jedes Muster weist je nach Umfang und Art der erforderlichen Änderungen unterschiedliche Komplexitätsmerkmale auf.

Muster	Description	Komplexität	Beispiele
API- und Servicemigrationen	Migration zwischen API-Versionen oder gleichwertigen Diensten unter Beibehaltung der Funktionalität	Mittel	AWS SDK v1→v2 (Java, Python, JavaScript), Boto2→Boto3, JUnit 4→5, Javax→Jakarta
Aktualisierungen der Sprachversionen	Aktualisierung auf neuere Versionen derselben Programmiersprache, Einführung neuer Funktionen und Ersatz veralteter Funktionen	Low-Medium	Java 8→17, Python 3.9→3.13, 12→22, Versionsupgrades Node.js TypeScript
Framework-Aktualisierungen	Aktualisierung auf neuere Versionen desselben Frameworks, Behebung grundlegender Änderungen	Mittel	Spring Boot 2.x→3.x, React 17→18, Angular-Upgrades, Django-Upgrades
Framework-Migrationen	Migration zu völlig anderen Frameworks, die ähnlichen Zwecken dienen	Hoch	Angular→React, Redux→Zustand, →React Vue.js
Upgrades für Bibliotheken und Abhängigkeiten	Aktualisierung von Bibliotheken von Drittanbietern auf neuere Versionen unter Beibehaltung derselben Sprache und desselben Frameworks	Low-Medium	Pandas 1.x→2.x, NumPy Upgrades, Bibliotheks-Upgrades, Hadoop/HBase/Hive Lodash-Upgrades
Code-Refactoring und Mustermodernisierung	Modernisierung von Codemustern und Übernahme von Best Practices, ohne die externe Funktionalität zu ändern	Low-Medium	Drucken→Logging-Frameworks, Verkettung von Zeichenketten→F-Strings, Übernahme von Typhinweisen, Instrumentierung der Beobachtbarkeit
File-by-File Drehbuch und Übersetzungen	Übersetzung unabhängiger Skripte oder Konfigurationsdateien, bei denen die Dateien größtenteils eigenständig sind	Low-Medium	AWS cdk→Terraform, Terraform→, Excel→Python-Notizbücher, CloudFormation Bash→ PowerShell
Architektur-Migrationen	Migration zwischen Hardwarearchitekturen oder Laufzeitumgebungen mit minimalen Codeänderungen	Medium-High	x86 →AWS Graviton (ARM), lokal → Lambda, herkömmlicher Server → Container
Language-to-Language Migrationen	Übersetzung von Codebasen von einer Programmiersprache in eine andere	Sehr hoch	Java→Python, JavaScript →, C→Rust, TypeScript Python→Go
Benutzerdefiniert Organization-Specific und Transformationen	Einzigartige organisatorische Anforderungen und spezielle Modernisierungsbedürfnisse	Variiert	Benutzerdefinierte interne Bibliotheksmigrationen, unternehmensspezifische Codierungsstandards, Migrationen proprietärer Frameworks

Anmerkung

Verwenden Sie für COBOL/mainframe Sprachen Transform for Mainframe. AWS Für Upgrades von.NET Framework auf .NET Core sollten Sie AWS Transform for Windows in Betracht ziehen. Für VMware-Migrationen zu AWS sollten Sie AWS Transform for VMware in Betracht ziehen.

Wie AWS Transformieren Sie benutzerdefinierte Werke

AWS Transform custom wird normalerweise in großen Projekten verwendet, bei denen mehrere Codebasen oder Module transformiert werden. Teams folgen in der Regel einem vierphasigen Arbeitsablauf:

Transformation definieren — Stellen Sie dem Agenten Eingabeaufforderungen, Dokumentation und Codebeispiele in natürlicher Sprache zur Verfügung, der daraufhin eine erste Transformationsdefinition generiert. Diese Definition kann iterativ durch Chat oder direkte Bearbeitung verfeinert werden. Diese Phase kann übersprungen werden, wenn Sie -verwaltete Transformationen verwenden AWS.

Pilotprojekt oder Proof-of-Concept — Testen Sie die Transformation anhand von Beispielcodebasen und verfeinern Sie sie anhand der Ergebnisse. Diese Validierungsphase hilft dabei, die Kosten und den Aufwand der vollständigen Transformation abzuschätzen. Kontinuierliches Lernen verbessert die Qualität in dieser Phase.

Skalierte Ausführung — Richten Sie mithilfe der CLI eine automatisierte Massenausführung ein, bei der Entwickler die Ergebnisse überprüfen und validieren. Überwachen Sie den Fortschritt mithilfe der Webanwendung und verfolgen Sie Transformationen in mehreren Repositorys.

Überwachung und Überprüfung — Kontinuierliches Lernen verbessert automatisch die Qualität der Transformation. Überprüfen Sie die Erkenntnisse, die aus früheren Durchläufen extrahiert wurden, um sicherzustellen, dass sie den Qualitätsstandards entsprechen, und archivieren Sie alle, die nicht nützlich sind.

Wichtige -Konzepte verstehen

In diesem Abschnitt werden die wichtigsten Konzepte für die Arbeit mit AWS Transform custom erklärt.

Transformationsdefinitionen

Eine Transformationsdefinition enthält die Anweisungen und das Wissen, die für die Durchführung einer bestimmten Codetransformation erforderlich sind. Sie wird als Fähigkeit dargestellt und besteht aus:

• SKILL.md(erforderlich) — Anweisungen in Markdown mit YAML-Front-Matter (nameund description -Feldern), die die Kerntransformationslogik und die Ausführungsanweisungen enthalten

• references/Ordner (optional) — Dokumentation, die bei Bedarf während der Transformationsausführung geladen wurde

• scripts/Ordner (optional) — Skripten, die die Transformation während der Ausführung herunterlädt und ausführt

AWS Transform CLI lädt Transformationsdefinitionen automatisch in das aktuelle Verzeichnis herunter, wenn sie zur Ausführung, Überprüfung oder Änderung benötigt werden.

Wichtig

Beim Veröffentlichen einer Transformation darf das Verzeichnis nur SKILL.md und optional den references/ Ordner, den scripts/ Ordner oder beides enthalten. Andere Dateien oder Unterverzeichnisse sind nicht zulässig.

Anmerkung

CLI Version 2.0 und höher verwendet das Skills-Format. Bestehende Transformationsdefinitionen werden automatisch von der CLI verarbeitet.

Kategorien von Transformationsdefinitionen

Eine Transformationsdefinition kann eine Kategorie haben, die angibt, wie sie verwendet wird:

• analysis— Liest Code und meldet Ergebnisse. Bei der kontinuierlichen Modernisierung werden diese Transformationsdefinitionen als benutzerdefinierte Analyse ausgeführt.

• remediation— Ändert den Code. Bei der kontinuierlichen Modernisierung werden diese Transformationsdefinitionen verwendet, um Fehler zu korrigieren.

Stellen Sie die Kategorie mit der --category Option atx custom def publish oder atx custom def save-draft ein:

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 verwendet die Kategorie, um zu entscheiden, wo eine Transformationsdefinition verwendet werden kann.

Verwenden Sie	Zulässige Transformationsdefinitionen
Benutzerdefinierte Analyse (--type custom)	Ihre eigenen Transformationsdefinitionen mit der analysis Kategorie
Sanierung mit --transformation-name	Ihre eigenen Transformationsdefinitionen mit der remediation Kategorie oder AWS verwaltete Transformationen

Bevor Transform eine benutzerdefinierte Analyse, einen Zeitplan oder eine Korrektur einreicht, überprüft AWS Transform die Kategorie der Transformationsdefinition.

Um die Kategorie einer Transformationsdefinition zu ändern, veröffentlichen Sie sie erneut mit einem anderen --category Wert. Wenn Sie eine neue Version ohne diese Option veröffentlichen--category, behält die neue Version die Kategorie der vorherigen Version bei.

Informationen zum Ausführen einer analysis Transformationsdefinition finden Sie unterBenutzerdefinierte Analyse.

Anmerkung

Eine Kategorie unterscheidet sich von einem Ressourcen-Tag. Informationen zur Verwaltung von Ressourcen-Tags finden Sie unterBefehle taggen.

Schreiben Sie eine Transformationsdefinition für die Analyse

Um nützliche Ergebnisse zu erhalten, schreiben Sie die Transformationsdefinition so, dass sie beschreibt, worauf zu achten ist, wie die einzelnen Probleme zu klassifizieren sind und was nicht. Wir empfehlen die folgenden Abschnitte unterSKILL.md.

Abschnitt	Was soll ich einschließen
Einführung	Ein oder zwei Sätze, die angeben, was die Analyse ergibt. Geben Sie an, dass es schreibgeschützt ist und keine Dateien ändern darf.
Einreisekriterien	Wenn die Analyse zutrifft, zum Beispiel „Das Repository enthält eine pom.xml build.gradle OR-Datei“.
Scope	Die Dateien und Verzeichnisse, die überprüft werden sollen, und die, die übersprungen werden sollen, wie z. B. die Build-Ausgabe und die Abhängigkeiten von Anbietern.
Was ist zu melden	Die spezifischen Muster oder Bedingungen, die als Problem gelten. Fragen Sie nach einem Ergebnis pro Problem mit dem Dateipfad und der Zeilennummer.
Kategorien	Ein kleiner, fester Satz von Kategoriewerten und Angaben dazu, welche Probleme zu den einzelnen Kategorien gehören.
Kriterien des Schweregrads	Was macht ein Problem aushigh,medium, oderlow.
Austrittskriterien	Woher der Agent weiß, dass es getan wurde: Jede Datei im Gültigkeitsbereich wurde geprüft, jedes Ergebnis hat eine Datei, Kategorie und Schweregrad, und es wurde keine Datei geändert. Geben Sie außerdem an, was gemeldet werden soll, wenn nichts gefunden wurde.

Im folgenden Beispiel werden Java-Projekte gefunden, die immer noch auf eine Java-Version vor 17 abzielen.

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

Wenn diese Transformationsdefinition für ein Projekt ausgeführt wird, dessen pom.xml Gruppen <source>1.8</source> vorhanden sind, führt sie zu einem high Schweregrad in der outdated-compile-target Kategorie, das AWS/java-version-upgrade als Lösung gilt.

Tipps zum Schreiben von Definitionen für Analysetransformationen

• Halten Sie es schreibgeschützt. Geben Sie ausdrücklich an, dass bei der Analyse keine Dateien geändert werden dürfen. Die Behebung von Problemen ist Aufgabe einer Problembehebung.

• Geben Sie genau an, was als Problem gilt. Benennen Sie die Dateien, Einstellungen und Muster, nach denen Sie suchen möchten. Vage Anweisungen führen zu widersprüchlichen Ergebnissen.

• Fragen Sie nach einem Ergebnis pro Ausgabe. Jedes Ergebnis sollte auf eine bestimmte Datei und Zeile verweisen, sodass es einzeln überprüft und behoben werden kann.

• Definieren Sie Schweregrad und Kategorien in der Transformationsdefinition. Der Agent verwendet Ihre Kriterien, um jedes Ergebnis zu klassifizieren.

• Konzentrieren Sie sich auf den Umfang. Bei einer benutzerdefinierten Analyse wird nur das gemeldet, was in der Transformationsdefinition beschrieben wird. Um viele Arten von Problemen zu finden, schreiben Sie separate Transformationsdefinitionen oder verwenden Sie die integrierten Analysetypen.

• Sagen Sie, was zu tun ist, wenn nichts gefunden wird. Ein Repository, das keine Probleme hat, liefert korrekt keine Ergebnisse.

• Nehmen Sie die Anweisungen zur Suche in die Transformationsdefinition auf. Wenn Sie die Konfiguration mit -g oder --configuration bei der Ausführung der Analyse übergeben, verwendet AWS Transform Ihre Konfiguration anstelle der Standardanweisungen. Wenn Sie den Abschnitt „Was zu melden ist“ beibehalten, SKILL.md führt die Transformationsdefinition zu Ergebnissen in beiden Fällen.

Testen Sie die Transformationsdefinition in einem Repository, von dem Sie wissen, dass es das Problem enthält, bevor Sie sie veröffentlichen. Speichern Sie es als Entwurf mitatx custom def save-draft, oder führen Sie es lokal mit aus atx ct analysis run (sieheBenutzerdefinierte Analyse).

Transformationsregistrierung

Das Transformationsregister ist das zentrale Repository Ihres AWS Kontos zum Speichern und Verwalten von Transformationsdefinitionen. Folgende Transformationen können in der Registrierung vorgenommen werden:

• Gelistet unter atx custom def list

• Wird in mehreren Codebasen ausgeführt

• Mit anderen Benutzern in Ihrem Konto geteilt AWS

• Version-controlled

Wichtig

Transformationsdefinitionen sind kontospezifisch. Wenn Sie eine Transformation in einem anderen AWS Konto verwenden möchten, müssen Sie sie separat in diesem Konto veröffentlichen.

Entwurf und veröffentlichte Transformationen

AWS Transform Custom unterstützt zwei Status für Transformationen in der Registrierung:

Bei Transformationsentwürfen handelt es sich um in Bearbeitung befindliche oder noch nicht getestete Transformationsdefinitionen. Sie werden als spezifische Versionen gespeichert und können von Benutzern abgerufen, aktualisiert und ausgeführt werden, die auf diese bestimmte Version verweisen. Entwürfe eignen sich für iteratives Entwickeln, Testen und Verfeinern, bevor die Transformation bereit ist, mit Ihrem Team geteilt zu werden. Entwürfe sind auch bestimmten Konversationen zugeordnet. Wenn Sie die CLI neu starten, können Sie atx --conversation-id {id} sie verwenden, um eine vorherige wiederherzustellen.

Veröffentlichte Transformationen stehen in der Transformationsregistrierung Ihres Kontos zur Ausführung durch andere Benutzer mit den erforderlichen IAM-Berechtigungen zur Verfügung. Veröffentlichte Transformationen können mithilfe von gefunden werden. atx custom def list

Der typische Arbeitsablauf ist:

1. Transformation lokal erstellen

2. Als Entwurf zum Testen speichern (atx custom def save-draft)

3. Verfeinern und validieren

4. Veröffentlichen Sie, um es mit Ihrem Team zu teilen (atx custom def publish)

Sie können eine Transformation auch direkt veröffentlichen, ohne sie als Entwurf zu speichern.

Referenzen im Vergleich zu Lektionen

AWS Transform custom verwendet zwei Arten von Wissen, um die Qualität der Transformation zu verbessern:

Referenzen sind vom Benutzer bereitgestellte Dokumentation, die im references/ Ordner einer Transformationsdefinition gespeichert wird. Verweise unterstützen nur Textdateien (insgesamt maximal 10 MB für alle Dateien) und enthalten in der Regel Dokumentation, API-Spezifikationen, Migrationshandbücher und Codebeispiele. Verweise werden bei der Ausführung der Transformation nach Bedarf geladen. Sie fügen Verweise hinzu, wenn Sie eine Transformationsdefinition im interaktiven Modus erstellen oder aktualisieren.

Lektionen werden automatisch aus früheren Durchläufen einer Transformation extrahiert. Das System für kontinuierliches Lernen generiert sie anhand von Ausführungsverläufen, Feedback von Entwicklern und Codekorrekturen, auf die es bei Transformationen stößt. Es gruppiert verwandte Lektionen in Kategorien, sodass Sie sie gemeinsam überprüfen können. Im Gegensatz zu Referenzen, die Sie im Voraus angeben, sammeln sich die Lektionen im Laufe der Zeit an, wenn Sie die Transformation über verschiedene Codebasen hinweg ausführen, und das System wendet sie automatisch an, um future Läufe zu verbessern. Sie überprüfen und verwalten die Lektionen interaktiv mit. atx custom def learnings

Befehle zum Erstellen und Überprüfen

Der Build- oder Validierungsbefehl ist ein optionaler Parameter, der angibt, wie Ihr Code während des Transformationsprozesses validiert werden soll. Dieser Befehl wird an verschiedenen Stellen während der Transformation ausgeführt, um die Codeintegrität sicherzustellen.

Die Bereitstellung eines Befehls, der die Ergebnisse validiert und Probleme zurückgibt, wenn die Validierung fehlschlägt, ist sehr wichtig, um die Transformationsqualität durch kontinuierliches Lernen zu verbessern. Wenn kein Build oder keine Validierung erforderlich ist, lassen Sie dies in Ihrer Eingabe weg.

Beispiele und ausführliche Anleitungen finden Sie unter Befehle zum Erstellen und Überprüfen im Abschnitt Workflows.

Kontinuierliches Lernen

Kontinuierliches Lernen ist ein System, das automatisch Feedback aus jeder Transformationsausführung erfasst und die Transformationsqualität im Laufe der Zeit verbessert. Das System sammelt Informationen durch:

• Explizites Feedback — Kommentare und Codekorrekturen werden im interaktiven Modus bereitgestellt

• Implizite Beobachtungen — Probleme, auf die der Agent beim Transformieren und Debuggen von Code stößt

Das System des kontinuierlichen Lernens verarbeitet diese Informationen, um Lektionen zu erstellen, die es der Transformationsdefinition hinzufügt, um future Transformationen zu verbessern. Das System führt den Lernprozess nach Abschluss der Transformationen automatisch durch, sodass keine zusätzlichen Eingaben von Ihnen erforderlich sind.

Wichtig

Die Lektionen sind transformationsspezifisch und werden nicht von verschiedenen Transformationen oder Kundenkonten gemeinsam genutzt.

Lektionen verwalten

Das System generiert automatisch Lektionen, aber Sie behalten die Kontrolle darüber, welche Lektionen es für future Läufe verwendet. atx custom def learningsMit dem Befehl wird eine interaktive Terminalsitzung geöffnet, in der die Lektionen, die sich im Zuge einer Transformation angesammelt haben, überprüft und kuratiert werden können.

In dieser Sitzung können Sie:

• Durchsuchen Sie Lektionen, die in Kategorien gruppiert sind, und sehen Sie, wie viele aktive Lektionen jede Kategorie enthält.

• Öffnen Sie eine Lektion, um alle Einzelheiten zu lesen, einschließlich des Hauptteils der Lektion, ihrer Auswirkungen und der Anzahl früherer Läufe, in denen sie konsultiert wurde.

• Archivieren Sie eine Lektion, um zu verhindern, dass das System sie bei future Läufen anwendet, und stellen Sie sie bei Bedarf später wieder her.

• Löschen Sie eine archivierte Lektion, die nicht mehr nützlich ist, dauerhaft.

Schrittweise Anleitungen hierzu finden Sie unter Kontinuierliches Lernen.

Client-Side Fähigkeiten

Client-side Fähigkeiten sind zusätzliche Fähigkeiten, die den Agenten bei Transformationsausführungen erweitern. Im Gegensatz zu Transformationsdefinitionen, die definieren, welche Transformation durchgeführt werden soll, bieten Fähigkeiten auf Kundenseite zusätzliche Tools, Skripte und Anweisungen, die der Agent bei jeder Transformation zusätzlich zu seinen integrierten Funktionen verwenden kann.

Client-side Fähigkeiten werden anhand von Verzeichnissen auf Projekt- und Benutzerebene ermittelt. Platzieren Sie Fähigkeiten auf Projektebene, wenn sie für ein Repository spezifische Standards durchsetzen, und auf Benutzerebene, wenn sie für all Ihre Projekte gelten. Project-level Fähigkeiten sind nur verfügbar, wenn ein Code-Repository-Pfad angegeben wird. Eine ausführliche Konfiguration und Verwendung finden Sie unterClient-Side Fähigkeiten.

Einführung in benutzerdefinierte Transformationsbefehle

Hier sind einige der Befehle, die Sie mit benutzerdefinierten Transformationen verwenden können. Die vollständige Liste der Befehle finden Sie in der Befehlsreferenz für benutzerdefinierte Transformationen AWS transformieren.

• atx custom

  • Führt eine interaktive Benutzererfahrung für benutzerdefinierte Transformationen aus und ermöglicht die Erstellung, Erkennung, Ausführung und Verfeinerung von Transformationen.

  • Dies ist der Standardbefehl für. atx

  • --trust-all-tools(-t) ist optional und lässt implizit alle vom Agenten angeforderten Werkzeuganforderungen zu. Verwenden Sie es mit Vorsicht, insbesondere in Produktionsumgebungen. Sie können die Vertrauensstellung von Tools für bestimmte Tools und Befehle mithilfe der Datei mit den Vertrauenseinstellungen konfigurieren.

• atx custom --help | atx custom -h

  • Zeigt das Hilfemenü an.

  • Jeder Befehl enthält auch ein Hilfemenü, zum Beispielatx custom def exec --help.

• atx --version | atx -v

  • Zeigt die Version an.

  • Die Versionsnummer ändert sich mit jeder Version.

• atx custom def list

  • Druckt eine Liste der Transformationen aus, die in der Transformationsregistrierung verfügbar sind.

• atx custom def exec

  • Führt eine Transformation aus

• atx custom def learnings

  • Öffnet eine interaktive Sitzung, in der die Erkenntnisse angezeigt und verwaltet werden können, die eine Transformation aus früheren Durchläufen gezogen hat

• atx mcp

  • Wird zur Verwaltung von MCP-Serverkonfigurationen verwendet