Azure Prepare

Azure Prepare 是什么

Azure Prepare 是 Microsoft 官方面向 Azure Developer CLI 工作流的部署准备 Skill。它分析现有工作区，区分新建、修改和现代化改造，选择 Azure 服务与 AZD、Azure CLI、Bicep 或 Terraform 配方，并生成部署计划、azure.yaml、基础设施代码和必要的 Dockerfile。它只负责准备，不直接执行真实部署。

适用场景与选择边界

适合用户明确要求使用 azd，或项目已经存在 azure.yaml 的场景，包括 Functions、事件驱动服务、Container Apps 和常见 Web 应用。Python App Service 纯代码发布、AWS 或 GCP 跨云迁移、AI Gateway 等有专门 Skill，应先路由过去；非 azd 部署也不应强行使用。

核心能力与工作机制

流程从工作区分析、需求收集、代码扫描、配方选择和架构规划开始，并要求持续维护 .azure/deployment-plan.md。研究相关服务后生成 IaC 与配置，应用身份与安全基线，进行本地功能验证，再把计划状态改为 Ready for Validation，交给 Azure Validate。

实际工作流

第一步就在工作区写出部署计划骨架，然后逐步补齐组件、规模、预算、服务映射和配方。计划必须先展示给用户批准，之后才生成文件。准备完成后确认订阅与区域、检查资源限制、验证应用功能，并明确停止在准备边界，不擅自运行 azd up 或 terraform apply。

输入、输出与交付物

输入是应用源码、依赖、用户对规模和预算的要求、部署工具偏好以及经确认的 Azure 上下文。输出包括 .azure/deployment-plan.md、azure.yaml、infra 目录中的 Bicep 或 Terraform、组件 Dockerfile 和相关配置；交付状态应明确为可验证，而不是声称已经上线。

依赖、账号与权限

需要读取并修改项目文件，按配方使用 azd、Azure CLI、Bicep 或 Terraform，并可能加载服务与 SDK 参考。确认订阅和区域需要有效 Azure 登录，但准备阶段应尽量避免改变云资源。生成的配置不得硬编码密钥，SQL Server Bicep 必须采用 Entra-only 身份验证。

限制与安全风险

错误的服务选择会造成成本、容量或维护负担；在已有项目里误用模板初始化可能覆盖用户代码。来源明确禁止删除项目或工作区，转换模板 IaC 时也只能移除被完全替代的模板文件，不能删除用户手写基础设施。所有破坏性操作与目标环境都要先确认。

适合谁使用

适合希望把现有应用规范化为 azd 部署项目的开发者、云架构师和平台团队，也适合从模板开始的新项目。只想执行已经准备好的部署应使用 Azure Deploy；只想做上线前检查则使用 Azure Validate。

上手与验收建议

先提供项目目录、期望环境、流量规模、预算和必须使用或禁止使用的 Azure 服务。审阅部署计划时重点检查组件到服务的映射、身份、网络、数据持久化和费用。验收应确认生成文件与现有代码兼容、本地功能仍正常、计划状态为 Ready for Validation。

来源、版本与许可

依据 microsoft/azure-skills 固定提交中的完整 Azure Prepare Skill、skills.sh 详情和 MIT 许可证整理。

常见问题

1. 为什么一开始就要创建部署计划骨架？

因为后续验证与部署都依赖同一份 .azure/deployment-plan.md。先建立骨架能让需求、架构、配方和决策逐步落盘，避免生成一堆文件后才发现目标环境或服务选择不一致。

2. 它会直接执行 azd up 吗？

不会。Azure Prepare 的边界是生成和整理部署所需产物，完成后把计划标记为 Ready for Validation 并交给 Azure Validate；真实部署命令由 Azure Deploy 管理。

3. 已有项目可以运行模板初始化吗？

不能在现有工作区随意使用带模板参数的 azd init，因为可能覆盖或重排用户代码。来源要求修改现有文件；只有确实适合时才可用不带模板的普通初始化，并保留原项目结构。

4. 如何在 Bicep 与 Terraform 之间选择？

应根据用户偏好、现有 IaC、团队能力和服务支持选择配方，并在部署计划里写明。若由模板 Bicep 转为 Terraform，只移除已经完全被替代的模板文件，保留用户手写文件。

5. SQL Server 管理员密码可以写入 Bicep 吗？

不可以。官方规则明确禁止生成 administratorLogin 和 administratorLoginPassword，即使放在条件分支也不行；应无条件使用 Entra-only 身份验证，避免产生静态高权限凭据。

6. 什么时候应改用其他 Azure Skill？

Python App Service 纯代码部署、AWS 或 GCP 迁移、AI Gateway 等命中专用路线时应先使用对应 Skill。Functions、Durable 和普通 azd 基础设施则继续留在 Azure Prepare。

7. 准备阶段需要确认订阅和区域吗？

需要。服务可用性、配额、命名和费用都依赖订阅与区域；应让用户确认目标上下文并检查资源供应限制，不能从当前登录状态默默推断生产环境。

8. 怎样判断准备工作已经完成？

部署计划已获批准并补全，所需配置、IaC 和容器文件已生成，安全规则已应用，本地功能验证通过，且计划状态已改为 Ready for Validation，随后必须交给 Azure Validate。