設計工作負載開發供應鏈的建議
適用於此 Azure 架構完善的架構營運卓越檢查清單建議：
| OE：06 | 建置工作負載供應鏈，透過可預測的自動化管線推動建議的變更。 管線會跨環境測試及升級這些變更。 優化供應鏈，讓您的工作負載可靠、安全、符合成本效益且高效能。 |
|---|
本指南說明根據持續整合和持續傳遞 （CI/CD） 管線來設計工作負載開發供應鏈的建議。 開發供應鏈，以確保您擁有可預測且標準化的方法可維護工作負載。 CI/CD 管線是供應鏈的體現，但您應有單一供應鏈。 您可能有數個管線依循相同的程序，並使用相同的工具。
納入供應鏈以保護您的工作負載，避免當您未正確管理工作負載變更時可能發生的損害。 請務必留意工作負載的狀態，因此您不會面臨無法預期的行為風險。 如果您需要花關鍵時間在發生問題時追蹤未記下變更，此風險會加劇。 若要將這些風險降到最低，請標準化定義供應鏈的程式和工具，並確保您的工作負載小組完全認可其使用。
[定義]
| 詞彙 | 定義 |
|---|---|
| 供應鏈 | 在雲端工作負載中，供應鏈是一套標準化的工具和程式，可用來影響整個環境的基礎結構和應用程序變更。 |
關鍵設計策略
注意
本指南中的建議是指程式代碼升級鏈結中的工作負載環境。 沙箱或其他探勘和概念證明環境需要較少的嚴謹性和結構。
下列建議可協助您定義供應鏈的核心原則。
強制執行自動化範本型部署的嚴格原則
透過供應鏈流程和工具進行建議的工作負載變更。 強制執行自動化範本型部署的嚴格原則。 此方法可協助您確保所有環境的工作負載組態都經過標準化、妥善定義及嚴格控制。 對於程式代碼升級鏈結中的環境，請勿使用手動程式或人為與雲端平臺控制平面互動，例如入口網站或 API 來執行更新。 遵循您定義的部署做法，透過管線合併環境的所有變更。 為了協助強制執行此原則，請考慮將只讀存取限制為預設值，並使用存取授權閘道來允許寫入存取。
此原則的一個重要層面是，所有變更都會建議變更，直到部署到生產環境為止。 透過自動化測試，例如整合和煙霧測試，可讓您的供應鏈自動拒絕變更。
將可重複且不可變的基礎結構部署為程序代碼
將可重複且不可變的基礎結構部署為程式代碼 （IaC）。 IaC 是描述性模型中基礎結構的管理，其使用鏡像原始程式碼的版本控制系統。 當您建立應用程式時，相同的原始程式碼將會在每次編譯時產生相同的二進位檔。 IaC 模型會以類似的方式，於每次套用時產生相同的環境。
納入 IaC，以確保您的小組遵循標準且完善的程式。 某些組織會指定單一個人或小組來部署及設定基礎結構。 當您實作完全自動化的程式時，基礎結構部署需要較少的個人管理。 責任會轉移至自動化程式與工具。 小組成員可以起始基礎結構部署，以維持一致性和品質。
將工作負載設計為一組邏輯元件，您可以將這些元件組合成一個範本，讓部署變得簡單且可重複。 您可以將這些套件組合 視為戳記 或 縮放單位。 如需詳細資訊，請參閱 部署戳記模式。 當您需要部署工作負載以相應放大至相同區域內的另一個區域或區域時，請使用管線來部署戳記。 根據您設計戳記的方式，您可能會部署工作負載的子集，而不是整個工作負載。 在 IaC 管線中包含網路元件，以確保您的部署戳記會自動連線到現有的資源。
若要將 IaC 管線優化以達到一致性和效率，請設計不可變的基礎結構，而不是可變的基礎結構。 實作不可變的基礎結構，以確保範圍中的所有系統都會同時以更新的組態取代，並與每個部署相同。
在所有環境中使用相同的部署成品集
在所有環境和管線中使用一組程式代碼資產和成品。 組織常見的痛點是當非商業執行環境不同於實際執行環境時。 手動建置實際執行環境和非商業執行環境可能會導致環境之間的設定不相符。 這項不符會減緩測試的速度，並讓變更更有可能損害生產系統。 IaC 方法可將這些問題降到最低。 當您使用 IaC 自動化時，您可以針對所有環境使用相同的基礎結構組態檔來產生幾乎相同的環境。 您可以將參數新增至基礎結構組態檔，並加以調整，以符合每個環境的需求。
為了控製成本，生產環境與非生產環境之間通常會有差異。 在非生產環境中，您通常不需要與生產環境中相同的備援和效能。 您的資源數目和 SKU 在環境之間可能會有所不同。 請務必使用標準化參數來控制並了解變異數，以協助您在進行變更時維持可預測性。
反映供應鏈中的組織結構
在供應鏈和管線設計中反映您的組織結構。 您的組織可能會在小組之間孤立。 每個小組都可能會管理供應鏈的一部分。 例如，許多組織都有管理基礎結構網域的小組，例如網路、數據和計算資源。 這些小組與管理應用程式開發、測試和部署的開發小組不同。 在某些組織中，開發和基礎結構小組會併入DevOps小組，共同管理所有基礎結構和應用程式部署。 有許多方式可以組織參與供應鏈的小組。 您的供應鏈依賴所有小組順暢地合作。 請確定所有小組都遵循標準程式，並使用標準工具來讓供應鏈盡可能有效率。
如果您外包部分工作負載生命週期，您的供應鏈可能會依賴第三方廠商。 這些廠商對於供應鏈的成功與內部資源一樣重要。 請確定所有小組都同意您使用的流程和工具。
選擇正確的部署方法
標準化您的部署方法。 請洽詢產品擁有者，了解工作負載可接受的生產停機時間長度。 視可接受的停機時間而定，您可以選擇適合您需求的部署方法。 在理想情況下，您應該在維護期間執行部署，以降低複雜性和風險。 如果沒有可接受的停機時間，請採用藍綠部署方法。
使用漸進式曝光方法，降低將未偵測到的錯誤引入大客戶的風險。 這個方法也稱為 Canary 部署，會以漸進順序部署到受控制的使用者群組。 它會在影響更多使用者之前攔截問題。 初始推出群組可能是客戶瞭解推出策略的子區段。 此小節的客戶可以容忍一些非預期的行為，並提供意見反應。 或者，這可能是一組內部使用者，這有助於在推出期間包含 Bug 的爆破半徑。
當您定義部署方法時，請採用標準原則，只部署每個部署中最小的可行變更。 根據工作負載的嚴重性和元件複雜度等因素，決定最小的可行變更。 如果您使用不可變的基礎結構，最小的可行變更通常是使用最新的組態來部署資源，以取代執行舊版的資源。 如果您使用可變基礎結構，您可能會決定最小的可行變更只是範圍中資源群組的單一更新。
遵循分層方法
請遵循分層方法來反映不同的生命週期。 在大部分的工作負載生命週期中，基礎層應該保持靜態，且應用層會經常變更。 若要考慮這些差異，您應該具備不同的管線，以影響每個層級的變更。
登陸區域位於最低層。 登陸區域是基礎元素的邏輯群組，例如訂用帳戶、管理群組、資源群組、治理函式和網路拓撲。 登陸區域可讓您輕鬆地部署和管理工作負載，並提供中央作業小組或平臺小組，以及環境設定的可重複方法。 為了提供一致的環境，所有 Azure 登陸區域都會提供一組常見的設計區域、參考架構、參考實作，以及修改部署以符合設計需求的程式。 Azure 登陸區域設計原則會根據原則驅動的治理，以及訂用帳戶民主化，提供建議的做法。 登陸區域在工作負載生命周期過程中需要最少的變更。 若要查看登陸區域的範例，請參閱 什麼是 Azure 登陸區域。 此概念架構提供一組建議用於 Azure 的意見。
您的核心基礎結構和功能，例如輸入和輸出網路控制站、負載平衡、網路路由解決方案、DNS 管理和核心伺服器，也應該需要不常的重大變更。 但是它們可能需要頻繁的組態更新。
您的應用程式和數據層需要頻繁的組態更新和頻繁的基礎結構變更。 這些元件應該具有最動態的管線。
納入完整的測試類型
規劃整體測試策略。 系統可靠性的核心原則是 左 移原則。 開發和部署應用程式是一個程式，其描述為從左至右的一系列步驟。 您不應該將測試限制為程序結尾。 盡可能將測試移轉至開頭或向左移。 當您早期抓住錯誤時，修復錯誤更便宜。 在稍後的應用程式生命週期中，它們可能很昂貴或無法修正。
測試所有程式代碼，包括應用程式程式代碼、基礎結構範本和組態腳本。 執行應用程式的環境應該受到版本控制，並透過與應用程式程式代碼相同的機制進行部署。 您可以使用小組已用於應用程式程式代碼的相同測試範例來測試及驗證環境。
可能的話，請使用自動化測試來確保一致性。 在您的供應鏈設計中包含下列類型的測試。
單元測試：單元測試通常會在持續整合例程中執行。 單元測試應廣泛且快速。 在理想情況下，它們應該涵蓋 100% 的程式代碼，並在 30 秒內執行。
實作單元測試，以確認個別程式代碼模組的語法和功能的運作方式，例如產生已知輸入的已定義輸出。 您也可以使用單元測試來確認 IaC 資產是否有效。
將單元測試套用至所有程式碼資產，包括範本和腳本。
煙霧測試：煙霧測試會確認工作負載可在測試環境中站立，並如預期般執行。 煙霧測試不會驗證元件的互操作性。
煙霧測試會確認基礎結構和應用程式的部署方法可運作，而且系統會在程式完成之後如預期回應。
整合測試：整合測試可確保應用程式元件會個別運作，然後判斷元件是否可以與其互動。
執行大型整合測試套件可能需要相當長的時間。 這就是為什麼最好在軟體開發生命週期中納入左移原則並執行測試。 針對您無法使用煙霧測試或單元測試來測試的案例，保留整合測試。
如有需要，您可以定期執行長時間的測試程式。 定期間隔提供良好的入侵，並偵測應用程式元件在推出后不晚於一天之間的互操作性問題。
某些測試案例受益於手動執行。 當您需要將人類互動元素引入測試時，請使用手動測試。
驗收測試：視內容而定，您可以手動執行驗收測試。 它可以部分或完全自動化。 驗收測試會判斷軟體系統是否符合需求規格。
此測試的主要目的是評估系統的符合商務需求，並判斷系統是否符合傳遞給使用者的必要準則。
在程式代碼升級程式中實作品質網關
透過測試在整個程式代碼升級程序中實作品質閘道。 將您的程式代碼部署至較低環境，例如開發和測試，以及透過較高的環境，例如預備和生產環境。 當您的部署通過品質網關時，請確定其符合您的質量目標，再變更進入生產環境。 您的商務需求會決定品質網關的重點。 也請考慮基本架構完善的架構原則：安全性、可靠性和效能效率。
同時將核准工作流程整合到您的品質網關中。 適當時清楚定義並自動化核准工作流程。 在自動化中定義品質驗收準則，讓您可以有效率且安全地穿過大門。
Azure 便利化
Azure DevOps 是一系列服務，可協助您建置共同作業、有效率且一致的開發實務。
Azure Pipelines 提供組建和發行服務，以支援應用程式中的 CI/CD。
適用於 Azure 的 GitHub Actions 與 Azure 整合，以簡化部署。 使用 GitHub Actions 將 CI/CD 程式自動化。 您可以建立工作流程，以建置和測試存放庫的每個提取要求，或將合併的提取要求部署至生產環境。
您可以使用 Terraform、Bicep 和 Azure Resource Manager 進行 IaC 部署。 根據您的需求和小組對工具的熟悉程度，您可以使用其中一或多個工具來部署和管理資源。
範例
如需示範如何使用 Azure Pipelines 建置 CI/CD 管線的範例，請參閱 Azure Pipelines 基準架構。
相關連結
卓越營運檢查清單
請參閱一組完整的建議。