As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Personalizada
O que é AWS Transformar de forma personalizada?
AWS O Transform Custom usa IA agente para realizar a modernização em grande escala de software, código, bibliotecas e estruturas para reduzir a dívida técnica. Ele lida com diversos cenários, incluindo atualizações de versões de idiomas, migrações de API e serviços, atualizações e migrações de estruturas, refatoração de código e transformações específicas da organização.
Por meio do aprendizado contínuo, o agente melhora a cada execução e feedback do desenvolvedor, oferecendo transformações repetíveis e de alta qualidade sem exigir conhecimento especializado em automação.
Principais recursos
AWS O Transform custom fornece os seguintes recursos:
Definição de transformação baseada em linguagem natural - Crie transformações personalizadas usando linguagem natural, documentação e exemplos de código
Execução da transformação - aplique transformações de forma consistente e confiável em várias bases de código
Aprendizado contínuo - Melhore automaticamente a qualidade da transformação em cada execução
AWS-transformações gerenciadas - Use transformações aprovadas e prontas para uso em cenários AWS comuns
Padrões de transformação
AWS O Transform custom oferece suporte a diversos padrões de transformação para atender às suas necessidades de modernização. Cada padrão tem características de complexidade diferentes com base no escopo e na natureza das mudanças necessárias.
| Padrão | Description | Complexidade | Exemplos |
|---|---|---|---|
| Migrações de API e serviços | Migração entre versões de API ou serviços equivalentes, mantendo a funcionalidade | Médio | AWS SDK v1→v2 (Java, Python,), Boto2→Boto3, JUnit 4→5, JavaScript javax→jacarta |
| Atualizações de versão de idioma | Atualização para versões mais recentes da mesma linguagem de programação, adoção de novos recursos e substituição de funcionalidades obsoletas | Low-Medium | Java 8→17, Python 3.9→3.13, 12→22, atualizações de versão Node.js TypeScript |
| Atualizações da estrutura | Atualização para versões mais recentes da mesma estrutura, abordando mudanças significativas | Médio | Spring Boot 2.x→3.x, React 17→18, atualizações Angular, atualizações do Django |
| Migrações de estrutura | Migração para estruturas totalmente diferentes que atendem a propósitos semelhantes | Alto | Angular→React, Redux→Zustand, →React Vue.js |
| Atualizações de bibliotecas e dependências | Atualizando bibliotecas de terceiros para versões mais recentes, mantendo a mesma linguagem e estrutura | Low-Medium | Pandas 1.x→2.x, atualizações, atualizações de bibliotecas, NumPy atualizações do Lodash Hadoop/HBase/Hive |
| Refatoração de código e modernização de padrões | Modernizando padrões de código e adotando as melhores práticas sem alterar a funcionalidade externa | Low-Medium | Imprimir→Estruturas de registro, concatenação de strings→f-strings, adoção de dicas de tipo, instrumentação de observabilidade |
| Roteiro e File-by-File traduções | Traduzindo scripts independentes ou arquivos de configuração em que os arquivos são, em sua maioria, independentes | Low-Medium | AWS CDK → Terraform, Terraform →, Excel → notebooks Python, Bash CloudFormation → PowerShell |
| Migrações de arquitetura | Migração entre arquiteturas de hardware ou ambientes de execução com o mínimo de alterações de código | Medium-High | x86 →AWS Graviton (ARM), no local → Lambda, servidor tradicional → contêineres |
| Language-to-Language Migrações | Traduzindo bases de código de uma linguagem de programação para outra | Muito alto | Java→Python, →, C→Rust, JavaScript Python→Go TypeScript |
| Personalização e Organization-Specific transformações | Requisitos organizacionais exclusivos e necessidades especializadas de modernização | Varia | Migrações personalizadas de bibliotecas internas, padrões de codificação específicos da organização, migrações de estruturas proprietárias |
nota
Para COBOL/mainframe idiomas, use AWS Transform for Mainframe. Para atualizações do.NET Framework para o.NET Core, considere o AWS Transform for Windows. Para migrações da VMware para AWS, considere o AWS Transform for VMware.
Como AWS Transforme trabalhos personalizados
AWS O Transform custom geralmente é usado em projetos de grande escala em que várias bases de código ou módulos são transformados. As equipes normalmente seguem um fluxo de trabalho de quatro fases:
Definir transformação - Forneça instruções em linguagem natural, documentação e exemplos de código para o agente, o que gera uma definição inicial de transformação. Essa definição pode ser refinada iterativamente por meio de bate-papo ou edições diretas. Essa fase pode ser ignorada ao usar transformações AWS gerenciadas.
Pilote ou Proof-of-Concept - Teste a transformação em bases de código de amostra e refine com base nos resultados. Essa fase de validação ajuda a estimar o custo e o esforço da transformação completa. O aprendizado contínuo melhora a qualidade durante essa fase.
Execução escalonada - Configure a execução em massa automatizada usando a CLI, com os desenvolvedores revisando e validando os resultados. Monitore o progresso usando o aplicativo web e acompanhe as transformações em vários repositórios.
Monitore e revise - O aprendizado contínuo melhora automaticamente a qualidade da transformação. Analise as lições que foram extraídas de séries anteriores para garantir que atendam aos padrões de qualidade e arquive as que não forem úteis.
Compreender os conceitos principais do
Esta seção explica os principais conceitos para trabalhar com o AWS Transform custom.
Definições de transformação
Uma definição de transformação contém as instruções e o conhecimento necessários para realizar uma transformação de código específica. É representado como uma habilidade e consiste em:
SKILL.md(obrigatório) - Instruções no Markdown com o frontmatter (nameedescriptioncampos) do YAML que contém a lógica de transformação principal e as instruções de execuçãoreferences/pasta (opcional) - Documentação carregada conforme necessário durante a execução da transformaçãoscripts/pasta (opcional) - Scripts que a transformação baixa e executa durante a execução
AWS O Transform CLI baixa automaticamente as definições de transformação para o diretório atual quando necessário para execução, inspeção ou modificação.
Importante
Ao publicar uma transformação, o diretório deve conter somente SKILL.md e, opcionalmente, a references/ pasta, a scripts/ pasta ou ambas. Nenhum outro arquivo ou subdiretório é permitido.
nota
A CLI versão 2.0 e posterior usa o formato de habilidades. As definições de transformação existentes são tratadas automaticamente pela CLI.
Categorias de definição de transformação
Uma definição de transformação pode ter uma categoria que diz como ela é usada:
analysis— Lê o código e relata as descobertas. A modernização contínua executa essas definições de transformação como uma análise personalizada.remediation— Altera o código. A modernização contínua usa essas definições de transformação para corrigir as descobertas.
Defina a categoria com a --category opção de atx custom def publish ouatx 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 usa a categoria para decidir onde uma definição de transformação pode ser usada.
| Use | Definições de transformação permitidas |
|---|---|
Análise personalizada (--type custom) |
Suas próprias definições de transformação com a analysis categoria |
Remediação com --transformation-name |
Suas próprias definições de transformação com a remediation categoria, ou transformações AWS gerenciadas |
Antes de enviar uma análise, cronograma ou remediação personalizada, o AWS Transform verifica a categoria da definição de transformação.
Para alterar a categoria de uma definição de transformação, publique-a novamente com um --category valor diferente. Se você publicar uma nova versão sem--category, a nova versão manterá a categoria da versão anterior.
Para saber como executar uma definição de analysis transformação, consulteAnálise personalizada.
nota
Uma categoria é diferente de uma tag de recurso. Para gerenciar tags de recursos, consulteComandos de tag.
Escreva uma definição de transformação para análise
Para obter descobertas úteis, escreva a definição de transformação para que ela descreva o que procurar, como classificar cada problema e o que não fazer. Recomendamos as seguintes seções emSKILL.md.
| Seção | O que incluir |
|---|---|
| Introdução | Uma ou duas frases que indicam o que a análise encontra. Declare que é somente para leitura e não deve modificar nenhum arquivo. |
| Critérios de entrada | Quando a análise se aplica, por exemplo, “O repositório contém um build.gradle arquivo pom.xml ou”. |
| Escopo | Os arquivos e diretórios a serem inspecionados e os que devem ser ignorados, como a saída da compilação e as dependências fornecidas. |
| O que denunciar | Os padrões ou condições específicos que contam como um problema. Solicite uma descoberta por problema, com o caminho do arquivo e o número da linha. |
| Categorias | Um conjunto pequeno e fixo de valores de categoria e quais problemas pertencem a cada um. |
| Critérios de gravidade | O que causa um problemahigh,medium, oulow. |
| Critérios de saída | Como o agente sabe que isso é feito: cada arquivo dentro do escopo foi inspecionado, cada descoberta tem um arquivo, uma categoria e uma severidade, e nenhum arquivo foi alterado. Indique também o que relatar quando nada for encontrado. |
O exemplo a seguir encontra projetos Java que ainda têm como alvo uma versão Java anterior à 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 essa definição de transformação é executada em um projeto cujos pom.xml conjuntos<source>1.8</source>, ela produz uma constatação de high severidade na outdated-compile-target categoria, com AWS/java-version-upgrade uma correção.
Dicas para escrever definições de transformação de análise
Mantenha-o somente para leitura. Declare explicitamente que a análise não deve modificar os arquivos. Corrigir problemas é o trabalho de uma remediação.
Seja específico sobre o que é considerado um problema. Nomeie os arquivos, configurações e padrões a serem procurados. Instruções vagas produzem resultados inconsistentes.
Solicite uma descoberta por problema. Cada descoberta deve apontar para um arquivo e uma linha específicos para que possa ser analisada e corrigida individualmente.
Defina a severidade e as categorias na definição da transformação. O agente usa seus critérios para classificar cada descoberta.
Mantenha o escopo focado. Uma análise personalizada relata somente o que sua definição de transformação descreve. Para encontrar vários tipos de problemas, escreva definições de transformação separadas ou use os tipos de análise integrados.
Diga o que fazer quando nada for encontrado. Um repositório sem problemas não produz corretamente nenhuma descoberta.
Inclua as instruções de descoberta na definição da transformação. Se você passar a configuração com
-gou--configurationao executar a análise, o AWS Transform usará sua configuração em vez das instruções padrão. Manter a seção “O que relatar”SKILL.mdfaz com que a definição de transformação produza descobertas de qualquer maneira.
Teste a definição de transformação em um repositório que você sabe que contém o problema antes de publicá-lo. Salve-o como rascunho com atx custom def save-draft ou execute-o localmente com atx ct analysis run (consulteAnálise personalizada).
Registro de transformação
O registro de transformação é o repositório centralizado da sua AWS conta para armazenar e gerenciar as definições de transformação. As transformações no registro podem ser:
Listado usando
atx custom def listExecutado em várias bases de código
Compartilhado com outros usuários em sua AWS conta
Version-controlled
Importante
As definições de transformação são específicas da conta. Se quiser usar uma transformação em uma AWS conta diferente, você deve publicá-la separadamente nessa conta.
Transformações preliminares versus transformações publicadas
AWS O Transform custom oferece suporte a dois estados para transformações no registro:
As transformações preliminares são definições de transformação em andamento ou não testadas. Eles são salvos como versões específicas e podem ser recuperados, atualizados e executados por usuários que se referem a essa versão específica. Os rascunhos são úteis para desenvolvimento, teste e refinamento iterativos antes que a transformação esteja pronta para ser compartilhada com sua equipe. Os rascunhos também estão associados a uma conversa específica. Se você reiniciar a CLI, poderá usá-la atx --conversation-id {id} para restaurar uma anterior.
As transformações publicadas estão disponíveis no registro de transformação da sua conta para execução por outros usuários com as permissões necessárias do IAM. As transformações publicadas podem ser descobertas usandoatx custom def list.
O fluxo de trabalho típico é:
Crie transformação localmente
Salvar como rascunho para teste (
atx custom def save-draft)Refine e valide
Publique para compartilhar com sua equipe (
atx custom def publish)
Você também pode publicar uma transformação diretamente sem salvá-la como rascunho.
Referências versus aulas
AWS O Transform custom usa dois tipos de conhecimento para melhorar a qualidade da transformação:
As referências são documentação fornecida pelo usuário armazenada na references/ pasta de uma definição de transformação. As referências oferecem suporte somente a arquivos de texto (máximo de 10 MB no total para todos os arquivos) e geralmente contêm documentação, especificações de API, guias de migração e exemplos de código. As referências são carregadas conforme necessário durante a execução da transformação. Você adiciona referências ao criar ou atualizar uma definição de transformação no modo interativo.
As aulas são extraídas automaticamente de execuções anteriores de uma transformação. O sistema de aprendizado contínuo os gera a partir de trajetórias de execução, feedback do desenvolvedor e correções de código encontradas durante as transformações. Ele agrupa as aulas relacionadas em categorias para que vocês possam analisá-las em conjunto. Ao contrário das referências, que você fornece antecipadamente, as aulas se acumulam ao longo do tempo à medida que você executa a transformação em diferentes bases de código, e o sistema as aplica automaticamente para melhorar futuras execuções. Você revisa e gerencia as aulas de forma interativa comatx custom def learnings.
Comandos de compilação e validação
O comando de compilação ou validação é um parâmetro opcional que especifica como validar seu código durante o processo de transformação. Esse comando é executado em vários pontos durante a transformação para garantir a integridade do código.
Fornecer um comando que valide os resultados e retorne os problemas se a validação falhar é muito importante para melhorar a qualidade da transformação por meio do aprendizado contínuo. Se nenhuma compilação ou validação for necessária, omita da sua entrada.
Para obter exemplos e orientações detalhadas, consulte Comandos de criação e validação na seção Fluxos de trabalho.
Aprendizagem contínua
O aprendizado contínuo é o sistema que captura automaticamente o feedback de cada execução da transformação e melhora a qualidade da transformação ao longo do tempo. O sistema coleta informações por meio de:
Feedback explícito - Comentários e correções de código fornecidos no modo interativo
Observações implícitas - Problemas que o agente encontra ao transformar e depurar o código
O sistema de aprendizado contínuo processa essas informações para criar lições que são adicionadas à definição de transformação para melhorar as transformações futuras. O sistema executa o processo de aprendizado automaticamente após a conclusão das transformações, sem exigir nenhuma entrada adicional de você.
Importante
As aulas são específicas para cada transformação e não são compartilhadas entre diferentes transformações ou diferentes contas de clientes.
Gerenciando aulas
O sistema gera aulas automaticamente, mas você mantém o controle de quais serão aplicadas às futuras corridas. O atx custom def learnings comando abre uma sessão de terminal interativa para revisar e organizar as lições que uma transformação acumulou.
Nesta sessão, você pode:
Procure aulas agrupadas em categorias e veja quantas aulas ativas cada categoria contém.
Abra uma aula para ler todos os detalhes, incluindo o corpo da aula, seu impacto e quantas edições anteriores a consultaram.
Arquive uma lição para evitar que o sistema a aplique em futuras execuções e restaure-a posteriormente, se necessário.
Exclua permanentemente uma lição arquivada que não é mais útil.
Para obter instruções detalhadas, consulte Aprendizagem contínua.
Client-Side Habilidades
Client-side habilidades são recursos adicionais que ampliam o agente durante as execuções de transformação. Diferentemente das definições de transformação que definem qual transformação realizar, as habilidades do lado do cliente fornecem ferramentas, scripts e instruções complementares que o agente pode usar junto com seus recursos integrados durante qualquer transformação.
Client-side as habilidades são descobertas nos diretórios no nível do projeto e no nível do usuário. Coloque as habilidades no nível do projeto quando elas aplicam padrões específicos para um repositório e no nível do usuário quando elas se aplicam a todos os seus projetos. Project-level as habilidades só estão disponíveis quando um caminho de repositório de código é fornecido. Para configuração e uso detalhados, consulteClient-Side Habilidades.
Introdução aos comandos de transformação personalizados
Aqui estão alguns dos comandos que você pode usar com transformações personalizadas. A lista completa de comandos está na referência de comandos AWS Transformar transformações personalizadas.
-
atx custom-
Executa uma experiência interativa de transformação personalizada, permitindo a criação, descoberta, execução e refinamento das transformações.
-
Esse é o comando padrão para
atx. -
--trust-all-tools(-t) é opcional e permite implicitamente todas as solicitações de ferramentas solicitadas pelo agente. Use com cuidado, especialmente em ambientes de produção. Você pode configurar a confiança da ferramenta para ferramentas e comandos específicos usando o arquivo de configurações de confiança.
-
-
atx custom --help|atx custom -h-
Mostra o menu de ajuda.
-
Cada comando também inclui um menu de ajuda, por exemplo,
atx custom def exec --help.
-
-
atx --version|atx -v-
Mostra a versão.
-
O número da versão muda a cada lançamento.
-
-
atx custom def list-
Imprime a lista de transformações disponíveis no registro de transformação.
-
-
atx custom def exec-
Executa uma transformação
-
-
atx custom def learnings-
Abre uma sessão interativa para visualizar e gerenciar as lições que uma transformação aprendeu em execuções anteriores
-
-
atx mcp-
Usado para gerenciar as configurações do servidor MCP
-