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