請參閱設計工作負載開發供應鏈的建議
適用於此 Power Platform Well-Architected 卓越運營清單建議：
| OE：06 | 透過可預測的自動化管道來建構能促進建議變更的工作負載供應鏈。 管道跨環境測試和提升這些變更。 優化供應鏈，使您的工作負載可靠、安全、經濟高效且高性能。 |
|---|
本指南介紹了設計基於持續整合與持續傳遞 (CI/CD) 管道的工作負載開發供應鏈的建議。 在雲端工作負載中，供應鏈是一套標準化的工具和流程，可用於影響跨環境的配置和工作負載變更。 開發供應鏈以確保您擁有可預測的標準化方法來維持工作量。 CI/CD 管道是供應鏈的體現，但您應該有一個單一的供應鏈。 您可能有多個管道跟隨相同的進程並使用相同的工具。
整合供應鏈以保護您的工作負載免受未正確管理工作負載變更所造成的損害。 始終瞭解工作負載的狀態，以免遇到不可預知的行為。 如果您需要在出現問題時花費關鍵時間來追蹤無法解釋的更改，則這種風險會加劇。 為了最大限度地降低這些風險，請標準化定義供應鏈的流程和工具，並確保您的工作負載團隊完全致力於使用它們。
關鍵設計原則
以下建議可以幫助您定義供應鏈的核心原則。
透過供應鏈流程和工具提出工作負載變更建議。 強制執行嚴格的基於範本的自動化部署策略。 此方法有助於確保所有環境中的工作負載配置都是標準化的、定義明確的且嚴格控制的。 對於程式碼升級鏈中的環境，請勿使用手動流程或手動互動來執行更新。 對於程式碼升級鏈中的環境，請勿使用手動流程或手動互動來執行更新。 為了幫助實施此策略，請考慮將存取權限限制為預設唯讀，並使用存取授權門來允許寫入存取。
這項原則的一個重要面向是，所有變更在部署到生產環境之前都是建議的變更。 透過整合和煙霧測試等自動化測試，您可以使供應鏈自動拒絕變更。
在所有環境和管道中使用一組程式碼資產和工件。 組織的一個常見痛點是非生產環境與生產環境不同。 手動建構生產和非生產環境可能會導致環境之間的配置不匹配。 這種不匹配會減慢測試速度，並使變更更有可能損害生產系統。
在供應鏈和管道設計中反映您的組織結構。 您的組織可能被多個團隊孤立。 每個團隊可能管理供應鏈的一部分。 例如，許多組織都有管理安全性和合規性設定或環境配置的團隊。 這些團隊與管理應用程式開發、測試和部署的開發團隊是分開的。 有很多方法可以組織參與供應鏈的團隊。 您的供應鏈依賴所有團隊的無縫協作。 確保所有團隊遵循標準流程並使用標準工具，使供應鏈盡可能有效率。
如果您將工作負載生命週期的部分外包，您的供應鏈可能會依賴第三方供應商。 這些供應商與內部資源一樣，對供應鏈的成功至關重要。 確保所有團隊都就您使用的流程和工具達成一致。
標準化您的部署方法。 與產品負責人討論您的工作負載可接受的生產停機時間。 根據可接受的停機時間 (如有) 多少，您可以選擇適合您要求的部署方法。 理想情況下，您應該在維護時段執行部署，以降低複雜性和風險。
規劃整體測試策略。 系統可靠性的核心原則是「左移」原則。 開發和部署應用程式的過程被描述為從左到右的一系列步驟。 您不應將測試限制在流程結束時。 盡可能將測試移至開頭或左側。 如果您及早發現錯誤，修復錯誤的成本會更低。 它們可能成本高昂，或者無法在應用程式生命週期的後期修復。
如果可能，請使用自動化測試來確保一致性。 在您的供應鏈設計中包含以下類型的測試：
單元測試：單元測試通常作為持續集成例程的一部分運行。 單元測試應該廣泛且快速。 理想情況下，它們應該覆蓋 100% 的程式碼。 將單元測試套用至所有程式碼資產，包括範本和腳本。
冒煙測試：冒煙測試驗證工作負載是否可以在測試環境中正常運行並按預期執行。 煙霧測試不驗證元件的互通性。 煙霧測試驗證基礎架構和應用程式的部署方法是否有效，以及系統在流程完成後是否如預期回應。
集成測試：集成測試確保應用程式元件單獨運行，然後確定元件是否可以按預期相互交互。 執行大型整合測試套件可能需要相當長的時間。 這就是為什麼最好在軟體開發生命週期的早期結合左移原則並執行測試的原因。 為無法使用煙霧測試或單元測試進行測試的場景保留整合測試。 如果需要，您可以定期執行長時間執行的測試進程。 定期間隔提供了一個很好的折衷方案，並在應用程式元件引入後一天內偵測到它們之間的互通性問題。 一些測試場景受益於手動執行。 當您需要將人類互動元素引入測試時，請使用手動測試。
驗收測試：根據上下文，您可以手動執行驗收測試。 它可以部分或完全自動化。 驗收測試確定軟體系統是否符合需求規格。 此測試的主要目的是評估系統是否符合業務要求，並確定系統是否滿足交付給使用者所需的標準。
通過測試在整個代碼提升過程中實施品質關卡。 將程式碼部署到較低的環境 (例如品質保證和測試) 以及較高的環境 (例如登台和生產)。 當您的部署通過品質關卡時，請確保在更改投入生產之前滿足您的品質目標。 您的業務需求決定了品質關卡的重點是什麼。 還要考慮基本的 Power Platform Well-Architected 原則：安全性、可靠性和性能效率。
還將審核工作流程整合到您的品質門中。 在適當的時候明確定義並自動化審核工作流程。 在您的自動化系統中定義品質驗收標準，以便您可以高效、安全地通過登機口。
Power Platform 簡易化
管道旨在通過 Power Platform 將 ALM 自動化以及持續集成和持續交付 (CI/CD) 功能引入服務，為 Power Platform Dynamics 365 客戶實現應用程式生命週期管理 (ALM) 的大眾化。
Microsoft Power Platform Build Tools for Azure DevOps 可用於自動執行與所構建 Power Platform應用程式相關的常見構建和部署任務。
GitHub Actions 使 Power Platform 開發人員能夠構建自動化的軟體開發生命週期工作流。 借助 Microsoft Power Platform 的 GitHub 動作，您可以在存放庫中建立工作流程，用來組建、測試、打包、發佈及部署應用程式；執行自動化以及管理機器人和 Power Platform 所建立的其他元件。
ALM Accelerator 是一個開源工具，由一組應用程式、腳本和管道組成，旨在自動化持續集成/持續交付過程。
使用 Azure Pipelines 自動執行測試。
Power Apps 檢查器 Web API 提供了一種機制，用於針對平臺的 Microsoft Dataverse 自定義項和擴展運行靜態分析檢查。
Microsoft Power Platform CLI ( PAC CLI) 是一個命令行工具，支援解決方案的 Power Platform 導入和匯出，以及打包到解決方案源檔和從 Power Platform 解決方案源檔解包。 PAC CLI 可作為 獨立的命令行工具 使用，也可作為 Code Visual Studio 的擴展使用。
可以使用 Terraform、Bicep 和 Azure 資源管理器進行不可變基礎結構即程式碼 (IaC) 部署。 根據您的要求以及您的團隊對這些工具的熟悉程度，您可以使用其中一個或多個工具來部署和管理資源。
組織一致性
雲端採用架構為中央團隊提供工作負載著陸區的指導。 工作負載登錄區域是工作負載的自定義供應鏈將應用程式部署到的位置。
有關詳細資訊，請參閱 什麼是 Azure 登陸區域？ 和 Azure 登陸區域設計原則。