通过

你当前正在访问 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 团队都可以分叉发布者存储库，使其自己的开发人员存储库可供其使用。
  • 每个团队都可以使用适用于 Visual Studio Code 的 API 管理 APIOps 或 API 管理扩展 从其开发 API 管理实例中提取相关项目。 这些项目基于 Azure 资源管理器，应提交到 API 团队的 Git 存储库。

    注释

    请勿使用 API 管理 Git 集成。

  • 服务模板和共享模板应位于单独的存储库中。
  • 应对提取的项目进行更改，然后将其提交到 Git。 这些都应部署到开发环境。
  • 为了提升到集中环境（过渡、生产等），API 团队可以提交拉取请求 (PR)，以将其更改合并到发布者存储库。
  • API 管理管理团队会验证 PR。
    • 理想情况下，大多数验证作为提交 PR 的一部分是自动化的。
  • 基础结构即代码模板应位于不同的存储库中，并部署在部署管道中。
    • 将基础结构部署与应用程序部署分开。 核心基础结构的更改频率低于应用程序。 将每种部署类型视为单独的流和管道。
  • 成功批准和合并更改后，API 管理团队可以配合商定的 API 团队计划将更改部署到集中管理的环境（过渡、生产）。

企业规模假设

以下是用于开发 API 管理登陆区域加速器的假设：

  • 使用基础设施即代码的 Bicep 文件来部署 API 管理基础设施和后端。
  • 使用管道部署基础结构模板。

后续步骤