你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
API 管理登陆区域加速器的平台自动化和 DevOps
本文提供使用 API 管理登陆区域加速器时的平台自动化和 DevOps 的设计注意事项和建议。 平台自动化和 DevOps 提供使用基础结构即代码选项实现环境部署方法现代化的机会。
详细了解平台自动化和 DevOps 设计领域。
设计注意事项
- 每个 API 团队都可以将更新从自己的开发人员存储库推送到自己的开发 API 管理实例。
- 从网络规划角度看，这意味着什么？
- 其他非生产性环境（例如 QA 或过渡）又如何？
- 考虑应如何对产品和其他实体进行管理或版本控制，尤其是在多个团队使用相同产品的情况下。
- 考虑针对 API 和策略的测试策略。
设计建议
- 中心团队（例如 API 管理管理团队）管理生产 API 管理环境。
- API 管理配置表示为资源管理器模板或等效的 Bicep 或 Terraform 模板，你应采用基础结构即代码思维模式。
- API 管理管理团队会将配置更改从 API 管理管理团队拥有的 Git 存储库（发布者存储库）发布到生产 API 管理环境。
- 每个单独的 API 团队都可以将发布者存储库分支，供其自己的开发人员存储库使用。
- 每个团队都可以使用 API 管理 APIOps 或适用于 Visual Studio Code 的 API 管理 扩展从其开发API 管理实例中提取相关项目。 这些项目基于 Azure 资源管理器，应提交到 API 团队的 Git 存储库。
注意
请勿使用 API 管理 Git 集成。
- 服务模板和共享模板应位于单独的存储库中。
- 应对提取的项目进行更改，然后将其提交到 Git。 这些都应部署到开发环境。
- 为了提升到集中环境（过渡、生产等），API 团队可以提交拉取请求 (PR)，以将其更改合并到发布者存储库。
- API 管理管理团队会验证 PR。
- 理想情况下，大多数验证都会在提交 PR 的过程中自动完成。
- 基础结构即代码模板应位于不同的存储库中，并部署在部署管道中。
- 将基础结构部署与应用程序部署分开。 与应用程序相比，核心基础结构的更改频率更低。 将每种类型的部署视为一个单独的流和管道。
- 成功批准和合并更改后，API 管理管理团队可以根据商定的 API 团队计划，将更改部署到集中管理的环境（过渡、生产）。
企业规模假设
下面是开发 API 管理登陆区域加速器时采用的假设：
- 使用基础结构即代码 Bicep 文件部署 API 管理基础结构和后端。
- 使用管道部署基础结构模板。