本文提供使用 API 管理登陸區域加速器時平臺自動化和 DevOps 的設計考慮和建議。 平臺自動化和 DevOps 提供機會，讓您使用基礎結構即程式代碼選項將環境部署的方法現代化。
深入瞭解 平臺自動化和DevOps 設計區域。
設計考量
- 每個 API 小組都可以將更新從自己的開發人員存放庫推送至自己的開發 API 管理實例。
- 從網路規劃的觀點來看，這是什麼意思？
- 其他非生產環境（例如 QA 或預備環境）呢？
- 請考慮產品和其他實體應如何管理或設定版本，特別是當多個小組使用相同的產品時。
- 請考慮 API 和原則的測試策略。
設計建議
- 中央小組（例如 API 管理管理小組）會管理生產 API 管理環境。
- API 管理設定會以 Resource Manager 範本或對等的 Bicep 或 Terraform 範本表示，而且應該採用基礎結構即程式代碼思維。
- API 管理小組會從 API 管理管理小組所擁有的 Git 存放庫（發行者存放庫）將設定變更發佈至生產 API 管理環境。
- 各個 API 小組可以派生發行者存放庫，以建立各自的開發存放庫來使用。
- 每個小組都可以使用適用於 Visual Studio Code 的 API 管理 APIOps 或 API 管理延伸模組 ，從其開發 API 管理實例擷取相關的成品。 這些工件是以 Azure Resource Manager 為基礎，應該提交至 API 小組的 Git 存放庫。
備註
請勿使用 API 管理 Git 整合。
- 服務範本和共用範本應該位於個別的存放庫中。
- 應對擷取的成品進行變更，然後提交至 Git。 這些應該要部署至開發環境。
- 為了升級至集中式環境（預備、生產等），API 小組可以提交提取要求（PR），將其變更合併至發行者存放庫。
- API 管理團隊會驗證 PR。
- 在理想情況下，大部分的驗證都會在提交PR時自動化。
- 基礎結構即程式代碼範本應該位於不同的存放庫中，並部署在部署管線中。
- 將基礎結構部署與應用程式部署分開。 核心基礎結構變更的頻率會比應用程式少。 將每種部署類型視為個別的流程和管線。
- 成功核准和合併變更之後，API 管理系統管理員小組就可以將變更部署至集中管理的環境（預備、生產環境），並與已同意的API小組排程協調。
企業級假設
以下是用於開發 API 管理登陸區加速器的假設：
- 使用基礎結構即程式代碼 Bicep 檔案來部署 API 管理基礎結構和後端。
- 透過管線部署基礎設施範本。
後續步驟
- 使用 APIOps 自動部署 API (機器翻譯)