共用方式為


適用于API 管理登陸區域加速器的平臺自動化和 DevOps

本文提供使用API 管理登陸區域加速器時,平臺自動化和 DevOps 的設計考慮和建議。 平臺自動化和 DevOps 可讓您使用基礎結構即程式碼選項將環境部署的方法現代化。

深入瞭解 平臺自動化和 DevOps 設計區域。

設計考量

  • 每個 API 小組都可以將更新從自己的開發人員存放庫推送至自己的開發API 管理實例。
    • 從網路規劃的觀點來看,這是什麼意思?
    • 其他非生產環境 (,例如 QA 或預備) 呢?
  • 請考慮應如何管理或設定產品和其他實體的版本,特別是當多個小組使用相同的產品時。
  • 請考慮 API 和原則的測試策略。

設計建議

  • 例如,中央小組 (,API 管理系統管理小組) 管理生產API 管理環境。
  • API 管理組態會以Resource Manager範本或對等的 Bicep 或 Terraform 範本表示,而且應採用基礎結構即程式碼思維。
  • API 管理系統管理員小組會將設定變更從 Git 存放庫發佈至生產API 管理環境, (發行者存放庫) 由API 管理系統管理員小組擁有。
  • 每個個別 API 小組都可以派生髮行者存放庫,讓自己的開發人員存放庫能夠從中工作。
  • 每個小組都可以使用 API 管理APIOpsAPI 管理 延伸模組,Visual Studio Code從其開發API 管理實例擷取相關的成品。 這些成品是以 Azure Resource Manager為基礎,應認可至 API 小組的 Git 存放庫。

    注意

    請勿使用 API 管理Git 整合

  • 服務範本和共用範本應該位於個別的存放庫中。
  • 對成品所做的變更應該對擷取的成品進行,然後認可至 Git。 這些應該部署至開發環境。
  • 為了 (預備、生產等) 升級至集中式環境,API 小組可以提交提取要求 (PR) ,將其變更合併至發行者存放庫。
  • API 管理系統管理員小組會驗證 PR。
    • 在理想情況下,大部分的驗證都會在提交 PR 時自動化。
  • 基礎結構即程式碼範本應該位於不同的存放庫中,並部署在部署管線中。
    • 分隔基礎結構部署和應用程式部署。 核心基礎結構的變更頻率比應用程式少。 將每種部署類型視為個別的流程和管線。
  • 成功核准和合併變更之後,API 管理系統管理員可以將變更部署至集中管理的環境, (預備環境、生產環境) 與已同意的 API 小組排程協調。

企業級假設

以下是進入API 管理登陸區域加速器開發的假設:

  • 使用基礎結構即程式碼 Bicep 檔案來部署API 管理基礎結構和後端。
  • 使用管線部署基礎結構範本。

下一步