用 Agentic Platform Engineering 消除迁移的重复性工作

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击此处.

Removing the Monkey Work of Migration with Agentic Platform Engineering — Git-Ape（git 智能体平台工程工具）将真实的 AWS Terraform 仓库迁移到 Azure 的演练，专注于提取部署意图而非逐行转换。

输入：contoso-migration

源项目是一个真实的 Terraform 项目（contoso-migration），在 AWS 上部署 Next.js 应用——EC2 用于计算，ALB 用于负载均衡，S3 用于制品，IAM 密钥用于身份认证。成本：约 34 美元/月。目标不是在 Azure 上复现相同的基础设施；而是弄清楚这个部署实际上要做什么，然后用 Azure 原生服务重新构建它。

步骤 1：验证与认证

Git-Ape 首先验证所有必需的 CLI 工具——az、aws、gh、jq、git——并在进行任何操作之前确认活跃的认证会话。不做部分运行。

步骤 2：意图提取

智能体通过 GitHub API 读取整个源仓库，并提取部署意图：运行时（Node.js）、计算类型、入口模式、制品处理、身份模型、网络和监控。这是关键步骤——它构建了一个关于部署做什么的语义模型，而不是它使用了哪些 Terraform 关键字。

步骤 3：服务映射

AWS 服务映射到 Azure 等效服务：

EC2 → App Service（Linux，Node 20 LTS）
ALB → App Service 内置负载均衡
IAM 角色/密钥 → Managed Identity
Terraform → Bicep + GitHub Actions

步骤 4：评审智能体

在生成输出之前，评审智能体运行并发现两个阻塞问题：

启动时构建反模式 — 原始 Terraform 在 EC2 启动时运行 npm install && npm run build。修复：在 CI 中构建，部署已就绪的制品。
不必要的 Blob Storage — S3 用于制品暂存，通过适当的 CI/CD 可以完全省去。评审智能体将其彻底删除。

步骤 5：生成的输出

结果是约 80 行 Bicep，而不是原来的 200 多行 Terraform。智能体创建了一个新的 GitHub 仓库，包含 infra/main.bicep 和 .github/workflows/deploy.yml，并删除了所有 AWS 特定文件。

安全态势对比

迁移还带来了显著的安全升级：

AWS 原始	Azure 输出
仅 HTTP	仅 HTTPS，TLS 1.2
SSH 对 0.0.0.0/0 开放	无 SSH 暴露
IAM 访问密钥	OIDC + Managed Identity
无监控	Application Insights

成本：约 13 美元/月，而原来是 34 美元/月。

与语法转换器的区别

评审智能体步骤是将其与机械翻译区分开来的关键。它发现了在 AWS 上可行但在 Azure 上会出错的模式——并修复了它们而不是复制它们。输出不是"Azure 语法的 AWS"；而是以更简洁方式实现同一目标的 Azure 原生部署。

请查看完整演练以获取完整的智能体追踪和生成的文件。

GitHub Copilot 的现代化评估是你还没用上的最好迁移工具

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

将传统 .NET Framework 应用迁移到现代 .NET 是那种每个人都知道应该做但没人想开始的任务。它从来不是简单的"更改目标框架"。而是消失的 API、不再存在的包、工作方式完全不同的托管模型，以及关于什么要容器化、什么要重写、什么要保持不变的无数小决策。

Jeffrey Fritz 刚刚发布了一篇 GitHub Copilot 现代化评估的深入解析，说实话？这是我见过的 .NET 最好的迁移工具。不是因为代码生成 — 那现在已经是标配了。而是因为它生成的评估文档。

它不仅仅是代码建议引擎

VS Code 扩展遵循评估 → 计划 → 执行模型。评估阶段分析你的整个代码库，生成一份结构化文档，捕获一切：什么需要更改、需要配置哪些 Azure 资源、使用什么部署模型。下游的一切 — 基础设施即代码、容器化、部署清单 — 都源自评估发现的内容。

评估存储在项目的 .github/modernize/assessment/ 下。每次运行产生一份独立的报告，因此你可以积累历史记录，并在修复问题时跟踪迁移态势的演变。

两种开始方式

推荐评估 — 快捷路径。从策划好的领域（Java/.NET 升级、云就绪、安全）中选择，无需配置即可获得有意义的结果。非常适合初次了解应用的状态。

自定义评估 — 定向路径。精确配置要分析的内容：目标计算（App Service、AKS、Container Apps）、目标操作系统、容器化分析。选择多个 Azure 目标来并排比较迁移方法。

那个比较视图真的很有用。一个应用在 App Service 上可能有 3 个必须解决的问题，在 AKS 上可能有 7 个。看到两者有助于在确定迁移路径之前做出托管决策。

问题分解是可操作的

每个问题都带有严重程度级别：

必须 — 必须修复，否则迁移失败
潜在 — 可能影响迁移，需要人工判断
可选 — 推荐的改进，不会阻止迁移

每个问题都链接到受影响的文件和行号，提供详细描述说明什么地方有问题以及为什么对目标平台重要，给出具体的修复步骤（不仅仅是"修复这个"），并包含官方文档链接。

你可以将单个问题分配给开发者，他们拥有行动所需的一切。这就是告诉你"有个问题"的工具和告诉你如何解决的工具之间的区别。

涵盖的升级路径

针对 .NET 具体来说：

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

每条升级路径都有检测规则，知道哪些 API 被移除、哪些模式没有直接等价物、哪些安全问题需要关注。

对于管理多个应用的团队，还有一个 CLI 支持多仓库批量评估 — 克隆所有仓库，全部评估，获取每个应用的报告加上汇总的组合视图。

我的看法

如果你坐拥传统 .NET Framework 应用（说实话，大多数企业团队都是这样），这就是那个应该开始使用的工具。仅评估文档就值得投入时间 — 它将模糊的"我们应该现代化"变成了一个具体的、有优先级的工作项列表，指明了前进的方向。

协作工作流也很聪明：导出评估、与团队分享、无需重新运行即可导入。决策者不是运行工具的人的架构评审？涵盖了。

总结

GitHub Copilot 的现代化评估将 .NET 迁移从一个可怕的、不明确的项目转变为一个结构化的、可跟踪的过程。从推荐评估开始了解你的现状，然后使用自定义评估来比较 Azure 目标并制定迁移计划。

阅读完整演练并获取 VS Code 扩展在你自己的代码库上试试。

Migration | The .NET Blog