技术债务长期困扰着企业开发团队，研究显示组织约 20% 的 IT 预算被用于修复旧代码而非开发新功能。为了解决这一痛点，AWS 推出了全新的智能代理——AWS Transform custom。它不仅提供针对 Java、Node.js 和 Python 的预置升级方案，还允许用户定义自定义的转换规则。通过自动学习和执行代码转换模式，该服务在许多场景下能减少高达 80% 的执行时间。无论是框架迁移（如 Angular 转 React）、SDK 更新，还是基础设施即代码（IaC）的标准化，AWS Transform custom 都能通过 CLI 或 Web 界面帮助团队高效完成，让开发者从繁琐的维护工作中解放出来，专注于业务创新。
文：Matheus Guimaraes / AWS
技术债务是当今企业开发团队面临的最棘手挑战之一。研究表明，组织将 20% 的 IT 预算花在了技术债务上，而不是用来提升新能力。无论是升级旧的框架、迁移到新的运行版本，还是重构过时的代码模式，这些必要但重复的任务消耗了宝贵的开发时间，而这些时间本应用于创新。
今天，我们很高兴宣布推出 AWS Transform custom。这是一个全新的智能代理，彻底改变了组织进行规模化现代化的方式。它结合了针对 Java、Node.js 和 Python 升级的预置转换功能，并具备定义自定义转换的能力。通过学习特定的转换模式并在整个代码库中自动执行，AWS Transform custom 帮助客户在许多案例中减少了高达 80% 的执行时间，从而让开发者能够专注于创新。
你可以利用文档、自然语言描述和代码示例来定义转换规则。随后，该服务会将这些特定模式一致地应用到成百上千个代码仓库中。它还能通过显式反馈和隐式信号（如开发者在转换项目中的手动修复）不断提高有效性。
AWS Transform custom 提供 CLI 和 Web 两种界面，以满足不同的现代化需求。你可以使用 CLI 通过自然语言交互来定义转换，并在本地代码库上交互式或自主地执行这些转换。你也可以将其集成到代码现代化流水线或工作流中，非常适合机器驱动的自动化场景。同时，Web 界面提供了全面的活动管理功能，帮助团队跨多个仓库跟踪和协调大规模的转换进度。
语言与框架的现代化升级
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 中的最佳实践和优化机会。
基础设施即代码（IaC）的转换是另一项关键能力，特别是当组织在评估不同的工具策略时。无论你是为了标准化目的将 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 现代化的转换，帮助团队立即上手。
上手指南——Python 版本升级实战
AWS Transform 通过预置和自定义转换功能，让复杂的代码转换变得易于管理。让我们通过一个常见的现代化挑战来探索如何使用现有转换：由于运行时支持终止（EOL），我们需要升级 AWS Lambda 函数。
在这个例子中，我将演示如何将一个 Python 3.8 的 Lambda 函数迁移到 Python 3.13，因为 Python 3.8 已达到 EOL 并不再接收安全更新。我将使用 CLI 进行演示，但也建议你探索 Web 界面强大的活动管理功能。
首先，我使用命令 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 -tAWS Transform 随即开始迁移过程。它分析我的 Lambda 函数代码，识别 Python 3.8 特有的模式，并自动应用兼容 Python 3.13 所需的更改。这包括更新已弃用功能的语法、修改导入语句以及调整任何特定于版本的行为。
执行后，它会提供一份综合摘要，包括：在 requirements.txt 中更新为兼容 Python 13 的依赖包报告、已替换为当前等效语法的弃用语法实例、用于 AWS Lambda 部署的更新运行时配置说明、验证迁移的建议测试用例等。它还提供了作为成功证明的证据体。
迁移后的代码位于本地分支中，你可以在满意后进行审查和合并。或者，你可以继续提供反馈并反复迭代，直到你对迁移完全完成并符合预期感到满意为止。
这个自动化过程将通常需要数小时的手动工作转变为简化、一致的升级，在保持代码质量的同时，确保与较新 Python 运行时的兼容性。
创建自定义转换——Angular 迁移实战
虽然 AWS 管理的转换能有效处理常见场景，但你也可以创建针对组织特定需求的自定义转换。让我们看看如何创建一个自定义转换，来了解 AWS Transform 是如何学习你的特定要求的。
我输入 atx 初始化 CLI 并开始流程。
它首先问我是想使用现有的转换还是创建一个新的。我选择创建一个新的。注意，从这里开始，整个对话都使用自然语言进行，而不是命令。
接着它提示我提供更多关于我想要执行的转换类型的信息。在这个演示中，我要迁移一个 Angular 应用程序，所以我输入“angular 16 to 19 application migration”，这会提示 CLI 搜索适用于此类迁移的所有可用转换。如果现有的转换没有完全匹配我的需求，它会询问我是从现有列表中选择还是创建一个自定义的。
我选择创建一个自定义转换。系统随后问我几个问题，包括是否有一些有用的文档、示例代码或迁移指南可以提供，以帮助定制转换计划。
在这个演示中，我只依赖 AWS Transform 为我提供良好的默认设置。我输入“I don’t have these details. Follow best practices.”（我没有这些细节，请遵循最佳实践）。CLI 回复说它将为从 Angular 16 迁移到 Angular 19 创建一个全面的转换定义。当然，如果你在这个阶段提供尽可能多的信息和相关数据，结果会更好。不过，你不需要一开始就拥有所有数据，可以在创建自定义转换定义的过程中随时补充。
转换定义生成为一个标记文件，包含摘要和按逻辑分组的详细实施步骤序列，如预迁移准备、处理和分区、静态依赖分析、搜索和应用特定转换规则，以及分步迁移和迭代验证。
有趣的是，AWS Transform 选择了增量框架更新的最佳实践，创建了先将应用程序迁移到 17，然后 18，最后 19 的步骤，而不是尝试直接从 16 跳到 19，以最大限度地减少问题。
请注意，该计划包括各个阶段的测试和验证，以确认各个阶段可以自信地结束。在最后，它还包括一个最终验证阶段，列出了退出标准，对应用程序的所有方面执行全面的测试集，用于验收迁移是否成功完成。
创建转换定义后，AWS Transform 询问我下一步想做什么。我可以选择审查或修改转换定义，并根据需要反复迭代。我也可以选择直接将此转换定义应用于 Angular 代码库。不过，首先我想将此转换提供给我的团队成员以及我自己未来使用。因此，我选择将其发布到注册表。
这个自定义转换需要一个名称和目标描述。AWS Transform 会自动从上下文中提取这些信息，并询问我是否需要修改。我很喜欢它建议的默认名称“Angular-16-to-19-Migration”，目标也陈述得很清楚，所以我选择接受建议并发布。
现在，转换定义已创建并发布，我可以多次针对任何代码仓库使用和运行它。让我们将转换应用于一个用 Angular 16 编写的项目代码仓库。此时我选择相应的选项，CLI 会询问我文件系统中应用程序的路径，以及可选的构建命令。
提供信息后，AWS Transform 开始分析代码库，并根据之前创建的定义制定详尽的分步转换计划。完成后，它会创建一个 JSON 文件，包含专门为此代码库设计的详细迁移计划。你可以像创建转换定义时一样，根据需要审查和迭代此计划。
当我准备接受该计划时，我可以使用自然语言告诉 AWS Transform 开始迁移过程。我输入“looks good, proceed”（看起来不错，继续），然后在 Shell 中观察它开始执行计划并一步步修改我的代码库。
所需时间取决于应用程序的复杂性。完成后，它会提供转换摘要以及计划最终验证阶段中每个退出标准的状态，并附带支持报告状态的所有证据。例如，“应用程序构建 – 生产环境”标准被列为通过，提供的证据包括增量 Git 提交、完成生产构建所需的时间、包大小、构建输出消息以及创建的所有输出文件的详细信息。
总结
AWS Transform 代表了组织处理代码现代化和技术债务方式的根本性转变。该服务将曾经分散的、各自为战的努力转变为统一的智能能力，消除了知识孤岛，使你的最佳实践和机构知识成为全组织可扩展的资产。这不仅加速了现代化举措，还让开发者能腾出更多时间进行创新和推动业务价值，而不是专注于重复性的维护和现代化任务。
须知事项
AWS Transform custom 现已全面上市。请访问入门指南开启你的首次转换战役，或查阅文档以了解更多关于设置自定义转换定义的详情。