推出 AWS Transform custom：通过人工智能驱动的代码现代化来消除技术债务



技术债务是当今企业开发团队面临的最持久的挑战之一。研究表明，企业将 20% 的 IT 预算花费在技术债务上，而不是用于推进新能力建设。无论是升级遗留框架、迁移到更新的运行时版本，还是重构过时的代码模式，这些必需但重复的任务消耗了开发者本可用于创新的宝贵时间。

今天，我们兴奋地宣布推出 AWS Transform custom，这是一个全新的智能体，它将从根本上改变组织大规模进行现代化的方式。该智能代理结合了用于 Java、Node.js 和 Python 升级的预置转换功能与自定义转换定义能力。通过学习特定的转换模式并将其自动化应用到整个代码库，使用 AWS Transform custom 的客户在许多情况下实现了高达 80% 的执行时间缩减，从而让开发者能够专注于创新。

您可以使用您的文档、自然语言描述和代码示例来定义转换规则。然后，该服务会将这些特定模式一致地应用于成百上千个代码存储库，并通过显式反馈和隐式信号（例如在您的转换项目中开发者进行的手动修复）来提高其有效性。

AWS Transform custom 提供 CLI 和网络界面，以适应不同的现代化需求。您可以使用 CLI 通过自然语言交互定义转换，并在本地代码库上以交互式或自主方式执行转换。您还可以将其集成到代码现代化管道或工作流中，使其成为机器驱动自动化的理想之选。同时，网络界面提供全面的活动管理功能，帮助团队大规模跟踪和协调多个存储库的转换进度。

语言和框架现代化
AWS Transform 支持运行时升级，无需提供额外信息，它不仅了解所需的语法更改，还了解新版本带来的细微行为差异和优化机会。这种智能方法同样适用于 Node.js、Python 和 Java 运行时升级，甚至扩展到基础设施级别的过渡，例如将工作负载从 x86 处理器迁移到 AWS Graviton。

它也能老练地应对框架现代化。当组织需要更新其 Spring Boot 应用程序以利用新功能和安全补丁时，AWS Transform custom 不仅仅是更新版本号，还能理解依赖项变更、配置更新和 API 修改的连锁影响。

对于面临更重大转变（例如从 Angular 迁移到 React）的团队，AWS Transform custom 可以学习使此类迁移成功的组件转换、状态管理转换和路由逻辑转换的模式，从而使此类迁移取得成功。

基础设施与企业级转换
在云服务持续改进的云环境中，跟上不断发展的 API 和 SDK 的挑战变得尤为严峻。AWS Transform custom 支持跨企业使用的多种编程语言（包括 Java、Python 和 JavaScript）进行 AWS SDK 更新。该服务不仅能理解 API 变更的机械层面，还能识别新 SDK 版本中可用的最佳实践和优化机会。

基础设施即代码转换代表了另一项关键能力，尤其是在组织评估不同的工具策略时。无论您是为了标准化目的将 AWS Cloud Development Kit (AWS CDK) 模板转换为Terraform，还是要更新 AWS CloudFormation 配置以访问新的服务功能，AWS Transform custom 都能理解这些工具的声明式本质，并能维护您基础设施定义的意图和结构。

除了这些常见场景，AWS Transform custom 还擅长解决那些在多年开发过程中积累的、组织特有的独特代码模式。每个企业都有自己的架构规范、实用程序库和编码标准，这些都需要随着时间推移而演进。它可以学习这些自定义模式，并帮助系统地重构它们，从而使机构知识和最佳实践能够在整个应用程序组合中得到一致的应用。

AWS Transform custom 的设计考虑了企业开发工作流，使卓越中心团队和系统集成商能够定义和执行组织范围的转换，而应用程序开发者则可以专注于审查和集成转换后的代码。然后，DevOps 工程师可以配置与现有持续集成和持续交付 (CI/CD) 管道和源代码控制系统的集成。它还包含用于 Java、Node.js 和 Python 运行时更新的预置转换（这对于 AWS Lambda 函数特别有用），以及用于 AWS SDK 现代化的转换，以帮助团队立即开始使用。

开始使用
AWS Transform 通过预置和自定义转换功能，使复杂的代码转换变得易于管理。首先，让我们探索如何使用现有转换来解决一个常见的现代化挑战：由于寿命终止 (EOL) 运行时支持终止而升级 AWS Lambda 函数。

在此示例中，我将演示如何将 Python 3.8 Lambda 函数迁移到 Python 3.13，因为 Python 3.8 已达到支持终止日期，不再接收安全更新。我将使用 CLI 进行此演示，但我鼓励你也探索网页界面强大的活动管理功能。

首先，我使用命令 atx custom def list 来探索可用的转换定义。果您愿意，也可以通过仅输入 atx 而非直接发出命令，通过对话界面访问此功能。

此命令显示所有可用的转换，包括 AWS 管理的默认转换 以及我的组织中用户创建的任何现有自定义转换。AWS 管理的转换以 AWS/ 前缀标识，表示它们由 AWS 维护和更新。在结果中，我可以看到几个选项，例如用于 Java 运行时现代化的 AWS/java-version-upgrade、用于更新 Python AWS SDK 使用的 AWS/python-boto2-to-boto3-migration、用于 Node.js 运行时更新的 AWS/nodejs-version-upgrade。

对于从 Python 3.8 到 3.13 的迁移，我将使用 AWS/python-version-upgrade 转换。

您可以使用命令 atx custom def exec 运行迁移。  请查阅文档，了解有关该命令及其所有选项的更多详细信息。在这里，我针对项目存储库运行该命令，并指定转换名称。我还添加了 pytest 来运行单元测试以进行验证。更重要的是，我在 --configuration 输入的 additionalPlanContext 部分中指定我要升级到的 Python 版本。作为参考，以下是我在演示中使用的命令（为了清晰起见，我在此处使用了多行和缩进格式）：

atx custom def exec 
-p /mnt/c/Users/vasudeve/Documents/Work/Projects/ATX/lambda/todoapilambda 
-n AWS/python-version-upgrade
-C "pytest" 
--configuration 
    "additionalPlanContext= The target Python version to upgrade to is Python 3.13" 
-x -t

然后，AWS Transform 开始迁移过程。它会分析我的 Lambda 函数代码，识别特定于 Python 3.8 的模式，并自动应用必要的更改以实现 Python 3.13 兼容性。这包括更新已弃用功能的语法、修改导入语句以及调整任何版本特定的行为。

执行后，它会提供一份全面的摘要，包括在 requirements.txt 中使用兼容 Python 3.13 的软件包版本更新的依赖关系的报告、已弃用语法替换为当前等效语法的实例、用于 AWS Lambda 部署的更新运行时配置说明、用于验证迁移的建议测试用例等等。它还提供一系列证据作为成功证明。

迁移后的代码位于本地分支中，因此您可以在满意时进行审查和合并。或者，您可以继续提供反馈并反复迭代，直到您确信迁移已完全完成并符合您的期望。

这个自动化过程将通常需要数小时手动工作的任务转变为一个简化、一致的升级过程，既能保持代码质量，又能保持与较新 Python 运行时的兼容性。

创建新的自定义转换
虽然 AWS 管理的转换可以有效处理常见场景，您也可以创建根据组织特定需求量身定制的自定义转换。让我们探索如何创建一个自定义转换，看看 AWS Transform 如何从您的特定需求中学习。

我输入 atx 来初始化 atx cli 并启动进程。

它首先询问我是要使用现有转换之一还是创建新转换。我选择创建新转换。请注意，从现在开始，整个对话都使用自然语言，而不是命令。我输入 new one，但也可以输入 I want to create a new one，它会以完全相同的方式理解。

然后，它提示我提供有关我想执行的转换类型的更多信息。在此演示中，我将迁移一个 Angular 应用程序，因此输入 angular 16 to 19 application migration，这会提示 CLI 搜索所有可用于此类迁移的转换。在我的案例中，我的团队已经创建并提供了几个 Angular 迁移，因此它向我展示了这些迁移。但它警告我，它们没有一个与我提出的从 Angular 16 迁移到 19 的特定请求完全匹配。然后它询问我是否想从列出的现有转换中进行选择，还是创建自定义转换。

我选择创建自定义转换，继续使用自然语言并输入 create a new one 作为命令。同样，只要您清楚地表明意图，这可以是该陈述的任何变体。接着，它问了我几个问题，包括我是否有任何有用的文档、示例代码或迁移指南可以提供，以帮助定制转换计划。

在此演示中，我将仅依靠 AWS Transform 为我提供良好的默认设置。我输入 I don't have these details.I want to create a new one.CLI 则回复我，它将创建一个用于从 Angular 16 迁移到 Angular 19 的全面转换定义。  当然，我依靠预训练的数据来根据最佳实践生成结果。与往常一样，建议在流程的这个阶段提供尽可能多的信息和相关数据，以取得更好的结果。但是，您无需预先准备好所有数据。在迭代创建自定义转换定义的过程中，您可以随时继续提供数据›。

转换定义生成为一个标记文件，包含摘要和全面的实现步骤序列，这些步骤按逻辑分组为多个阶段，例如迁移前准备、处理和分区、静态依赖分析、搜索和应用特定的转换规则，以及逐步迁移和迭代验证。

有趣的是，AWS Transform 选择了执行增量框架更新的最佳实践，创建了先将应用程序迁移到 17、然后到 18、再到 19 的步骤，而不是试图直接从 16 迁移到 19，以最大限度地减少问题。

请注意，该计划包括各个阶段的测试和验证，以确认各个阶段可以放心地完成。它还包括一个最终验证阶段，列出了退出标准，这些标准将对应用程序的各个方面执行一套全面的测试，用于认定迁移成功完成。

创建转换定义后，AWS Transform 询问我接下来想做什么。我可以选择审查或修改转换定义，可以根据需要反复进行此过程，直到得到满意的定义为止。我也可以选择将此转换定义立即应用到 Angular 代码库。但是，首先我想让团队成员以及我自己也能使用此转换，以便我们将来都可以再次使用它。因此，我选择选项 4 将此转换发布到注册表。

此自定义转换需要其目标的名称和描述，用户浏览注册表时会显示该名称和描述。AWS Transform 自动从上下文中为我提取了这些信息，并询问我在继续之前是否要修改它们。我喜欢“Angular-16-to-19-Migration”这个合理的默认值，并且目标陈述清晰，因此我选择接受建议并通过回答 yes, looks good 来发布。

现在，转换定义已创建并发布，我可以使用它，并针对任何代码存储库多次运行。让我们将此转换应用到一个包含用 Angular 16 编写的项目的代码存储库。现在，我从后续提示中选择选项 1，CLI 会询问我文件系统中要迁移的应用程序的路径，以及它应该使用的构建命令（可选）。

在我提供这些信息后，AWS Transform 继续分析代码库，并根据之前创建的定义制定全面的分步转换计划。完成后，它会创建一个 JSON 文件，其中包含专门为将我们的转换定义应用到此代码库而设计的详细迁移计划。与创建转换定义的过程类似，您可以根据需要反复审查和迭代此计划，提供反馈并根据您可能有的任何特定要求进行调整。

当我准备接受该计划时，我可以使用自然语言告诉 AWS Transform 我们可以开始迁移过程。我输入 looks good, proceed，然后在 shell 中观察进度，因为它开始执行计划并一步一步地对代码库进行更改。

它所花费的时间将根据应用程序的复杂性而有所不同。在我的案例中，它花了几分钟才完成。完成后，它会向我提供转换摘要以及计划最终验证阶段中包含的每个退出标准的状态，并附带所有证据来支持报告的状态。例如，Application Build – Production 标准被列为“passed”，提供的一些证据包括增量 Git 提交、完成生产构建所需的时间、包大小、构建输出消息以及有关创建的所有输出文件的详细信息。

结论
AWS Transform 代表了组织进行代码现代化和技术债务处理方式的根本性转变。该服务有助于将曾经零散、逐个团队进行的工作，转变为一个统一的智能能力，消除了知识孤岛，使您的最佳实践和机构知识能够作为可扩展的资产在整个组织中使用。这有助于加速现代化计划，同时让开发者能够腾出更多时间专注于创新和推动业务价值，而不是专注于重复的维护和现代化任务。

注意事项

AWS Transform custom 现已正式推出。请访问入门指南，开始第一个转换活动，或查看文档以了解有关设置自定义转换定义的更多信息。