運用 Microsoft Power Platform 的 ALM 基本知識
本文描述實施應用程式生命週期管理（ALM）所需元件、工具和流程。
環境
環境是儲存、管理和共享組織商務資料、應用程式及商務流程的空間。 它們也充當不同應用程式的容器，這些應用程式可能有不同角色、安全性需求或目標對象。 每個環境只能有一個 Microsoft Dataverse 資料庫。 其他資訊：環境概觀
重要
當您建立環境時，您可以選擇安裝 Dynamics 365 應用程式，例如 Dynamics 365 Sales 和 Dynamics 365 Marketing。 此時務必判斷是否需要這些應用程式，因為無法稍後再解除安裝或進行安裝應用程式。 如果您並不以之為基礎進行建置，而且日後也不需要這些應用程式時，建議您不要將應用程式安裝在環境中。 這將有助於避免當您在環境間分佈解決方案時的相依性複與複雜性。
ALM 中使用的環境類型
您可以使用 Power Platform 管理中心建立這些類型的 Power Platform 環境：
沙箱：沙箱環境是任何 Dataverse 的非實際執行環境。 沙箱環境與生產環境隔離，是降低風險、安全進行開發並測試應用程式變更的位置。 沙箱環境包括在實際執行環境中會產生傷害的功能，例如重設、刪除及複製作業。 其他資訊：管理沙箱環境
生產：應用程式和其他軟體投入原本使用的環境。
開發人員 (正式名為 Community)。 Power Apps 開發人員方案可讓您存取 Power Apps 進階功能、Dataverse，和 Power Automate 方便個人使用。 此計劃主要用於使用 Power Apps、Power Automate 和 Microsoft Dataverse 來建置和測試，或用於學習目的。 開發人員環境是單一使用者環境，不能用來執行或分享生產應用程式。
預設：自動為每個用戶建立單一預設環境，此環境由該用戶中所有的使用者所共用。 租用戶辨別會有一個或多個關聯性 Microsoft 訂閱和服務的客戶。 只要新使用者註冊 Power Apps，他們會自動加入預設環境的決策者角色。 預設環境會在最接近 Microsoft Entra 租用戶預設區域的區域建立，而且命名為：「{Microsoft Entra 租用戶名稱} (預設)」
為特定目的 (例如開發、測試或生產) 建立和使用正確的環境。
有關環境的詳細資訊，請參閱環境概觀。
誰應擁有存取權？
在 Microsoft Dataverse 中定義和管理您的資源和資料的安全性。 Microsoft Power Platform 提供環境級的管理員角色以執行任務。 Dataverse 包括定義應用程式、應用程式元件和資源應用程式決策者與 Dataverse 內使用者的存取層級。
| 環境用途 | 具有存取權的角色 | 註解 |
|---|---|---|
| 開發 | 應用程式決策者和開發人員。 | 應用程式使用者不應具有存取權。 開發人員至少需要環境決策者資訊安全角色才能建立資源。 |
| 測試 | 系統管理員和正在測試的人員。 | 應用程式決策者、開發人員和生產應用程式使用者不應具有存取權。 測試使用者應該只有足以執行測試的權限。 |
| 生產 | 管理員和應用程式使用者。 使用者應該只有足以為他們使用的應用程式執行任務的存取權。 | 應用程式決策者與開發人員不應具有存取權，或應該只有使用者層級的權限。 |
| 預設 | 根據預設，在您租用戶中的每位使用者都可在 Dataverse 資料庫的預設環境中建立和編輯應用程式。 | 我們強烈建議您須針對特定目的建立環境，並只將適當的角色和權限授與需要的人使用。 |
其他資訊：
解決方案
解決方案是用來將應用程式和元件從一個環境傳輸到另一個環境，或是將一組自訂套用到現有的應用程式。
解決方案特色如下：
它們包括中繼資料以及具有組態資料的實體。 解決方案不包含任何業務資料。
它們會包含許多不同 Microsoft Power Platform 元件，例如模型導向應用程式、畫布應用程式、網站地圖、組織、實體、表單、自訂連接器、web 資源、選項群組、圖表和欄位。 請注意，並不是所有的實體都會包括在解決方案中。 例如，應用程式使用者、自訂 API 及組織設定系統資料表無法新增至解決方案。
它們會封裝成預計匯出和匯入到其他環境的單位，或者解構與簽入資產控制為資產原始程式碼。 解決方案也用來將變更內容套用到現有的解決方案。
受管理的解決方案可用來部署到任何不是該解決方案開發環境的環境。 這包括測試、使用者接受度測試（UAT）、系統整合測試（SIT）和生產環境。 受管理的解決方案可獨立於環境中的其他受管理解決方案提供服務（升級、修補和刪除）。 作為 ALM 最佳作法，受管理的解決方案應由生成伺服器生成，並視為生成專案。
受管理解決方案更新版已部署到其之前版本。 這並不會建立其他的解決方案層。 您無法使用更新刪除元件。
修補程式只包含上層受管理解決方案的變更。 只有在進行少量更新（類似 Hotfix）時才應使用修補程式，而且您可能需要卸載移除它。 匯入修補程式時，這些修補程式會層疊在上層解決方案的最頂端。 您無法使用修補程式刪除元件。
升級解決方案會直接在基本層和任何現有的修補程式上安裝新解決方案層。
套用解決方案升級涉及刪除所有現有的修補程式和基本層。
解決方案升級將會刪除已存在，但已不再包含在升級版本中的元件。
其他資訊：解決方案概念
原始檔控制
原始程式碼控制（也稱為版本控制）是一種維護與安全儲存軟體開發資產並跟蹤資產變更的系統。 當多個應用程式決策者和開發人員共同處理相同的檔案集合時，變更追蹤就顯得特別重要。 原始程式碼控制系統也讓您有能力復原變更或還原已刪除檔案。
原始程式碼控制系統協助組織取得完善的 ALM，因為在原始程式碼管理系統維護的資源是「單一真實原始程式碼」或，換句話說，是您的解決方案的單一存取和修改點。
分支和合併策略
幾乎每個原始程式碼管理系統都有某種形式的分支和合併支援。 分流表示您偏離主要的開發行並繼續工作，毋須變更主行。 匯流流程包含將一個分支與另一個分支結合，例如從開發分支到主行分支。 一些常見的分支策略是主幹式分支、釋放分支和功能分支。 其他資訊：採用 Git 分支策略
使用解決方案的原始程式碼管理程式
當您使用原始程式碼控制系統中的解決方案時，您可以使用兩條主要路徑：
- 匯出非託管解決方案並將它放在原始程式碼控制系統中解壓縮。 建構流程會將封裝的解決方案匯入為臨時建構環境（沙箱環境）。 接著將解決方案匯出為託管解決方案並儲存為原始程式碼管理系統中的建構成品。
- 將解決方案匯出為非託管方案，也將其匯出為受託管方案，並將兩者放入原始程式碼控制系統中。 雖然這套方法不需要建構環境，但它確實需要維護所有元件的兩個複本（從非託管解決方案的所有非託管元件複本及受託管解決方案的所有受託管元件複本）。
其他資訊： 建構工具任務
動畫
自動化是應用程式生命週期的關鍵部份，專門改善 ALM 的效率、可靠性、品質和效能。 除了建立和重設沙箱環境以外，自動化工具和任務可用來驗證、匯出、封裝、解壓縮和匯出解決方案。
其他資訊：什麼是 Microsoft Power Platform Build Tools？
使用共用原始程式碼管理的團隊開發
詳加考慮您與您的開發團隊如何協同運作，建立專案是很重要的。 打破小倉庫和開後視圖及談話可讓您的團隊提供更好的軟體。 一些工具和工作流程 (例如 Git、GitHub 和 Azure DevOps) 提供的工具和工作流程是專門用來達到快速改善通訊和軟體品質的目的。 請注意，在解決方案系統中搭配組態會為團隊開發帶來挑戰。 組織必須協調多名開發人員的變更以盡可能避免合併衝突，因為原始程式碼管理系統會對如何合併設限。 我們建議您避免多人同時變更複雜元件 (例如表單、流程和畫布應用程式)。
其他資訊：情境劇本 5: 支援團隊開發
持續整合和部署
您可以使用任何原始程式碼控制系統建立要開始使用的管道，以便持續整合與持續部署（CI/CD）。 不過，本指南強調 GitHub 和 Azure DevOps。 GitHub 是由數百萬名開發人員使用的開發平台。 Azure DevOps 提供開發人員服務，以支援團隊規劃工作、共同處理代碼開發及建構與部署應用程式。
若要開始使用，您需要：
其他資訊：建立您的第一個管道
授權
若要使用 Power Apps 和 Power Automate 建立或編輯應用程式和流程，使用者必須分別有 Power Apps 或 Power Automate 使用者授權或適當的 Dynamics 365 應用程式授權。 如需詳細資訊，請參閱 Microsoft Power Platform 授權總纜。 我們也建議連絡您的 Microsoft 帳戶代表討論您的授權需求。
ALM 考量因素
當您將「ALM」視為在 Microsoft Power Platform 上建立應用程式的整體組成部分時，它會大幅改善應用程式的速度、可靠性和使用者體驗。 它也能確保多名開發人員，傳統開發人員撰寫程式碼和公民開發人員，共同參與建立的應用程式。
請參閱下列討論任何應用程式開發開始時須考慮幾個項目的文章：