在建立解決方案之前，請花一些時間提前規劃您的環境策略和解決方案策略。 考慮以下幾個方面：
| 層面 | 考量事項 |
|---|---|
| 應用程式範圍 | 您的實作是否跨越多個應用程式，例如銷售、客戶服務、現場服務、財務等？ |
| 發佈節奏 | 您計劃多久將更新部署至生產環境？ 您的交付方法是否基於衝刺週期等敏捷實踐？ |
| 生產支持 | 如何在不過早引入新功能的情況下處理生產中的緊急修復？ |
| 解決方案架構 | 您管理了多少個解決方案？ 這些解決方案是共用元件還是相互依賴？ |
| 環境規劃 | 您需要多少個 Microsoft Dataverse 環境來支援您的開發生命週期？ 您需要單獨的開發、測試和生產環境嗎？ 開發人員是在共享環境中協作工作，還是需要隔離的環境才能獨立工作？ |
以下部分概述了三種策略，從最簡單到最複雜，並重點介紹了它們各自的優缺點。
單一解決方案策略
在開發期間，所有自訂都會分組為一個非受控解決方案，稍後會匯出為單一受控解決方案以進行部署。
推薦用於：
- 中小型實作
- 未來不太可能模組化的場景
| 優勢 | 劣勢 |
|---|---|
| 簡化環境設定和管理。 | 如有必要，需要更多努力來稍後擴展或模組化。 |
| 簡化的部署。 只需一種解決方案即可管理，跨環境匯出和匯入非常簡單且不易出錯。 | 包含大量自訂的單一解決方案可能會導致部署時間較長。 若要減少解決方案大小， 請使用表格分割。 若要縮短匯入時間，請前往 效能建議。 |
| 更容易定位、審核和管理變更。 | 當多個開發者在相同開發環境中工作時，他們有覆寫彼此變更的風險。 透過實施原始碼版本控制、採用分支策略以及為每個分支使用專用的開發環境，可以降低這種風險。 原始碼版本控制和分支策略提供變更追蹤、協作支援和衝突解決機制。 其他資訊： 採用 Git 分支策略。 |
Note
Microsoft Power Platform 的最新改進減少了受控解決方案的匯入時間，包括使用升級選項的解決方案。 這些最佳化包括更好地處理元件相依性，以及減少未變更元件的額外負荷。 若要瞭解如何從這些改善中獲益，請前往 效能建議。
同一開發環境中的多個解決方案
多個非託管解決方案在單一開發環境中維護，每個解決方案通常專用於不相關的功能或模組。
推薦用於：
- 具有不同且獨立功能區域且不共用元件的中小型實作。
| 優勢 | 不利 |
|---|---|
| 簡化環境設定和管理。 | 在相同的開發環境中維護多個非受管理解決方案會增加相依性衝突的可能性。 例如，您可能會遇到無法匯入解決方案 A 的情況，因為它相依於解決方案 B，而解決方案 B 則無法匯入，因為它相依於解決方案 A。 |
| 功能區域可以彼此獨立部署。 | 在相同開發環境中工作的多個開發人員可能會覆寫彼此的變更。 在非受控解決方案中工作不會提供隔離。 每項修改都會直接套用至環境中，不論編輯的是哪個方案。 |
Note
當您在相同的開發環境中有多個解決方案時，在將受管理解決方案匯入目標環境之後，您通常會建立層。 其他資訊： 解決方案層和合併行為
請務必注意：
- 請勿在多個解決方案中包含相同的非受控元件。
- 只保留一個包含所有資料表的解決方案。 不要有兩個不同的解決方案，其中兩者都包含表格。 這是因為資料表之間的單一關聯通常會有風險，這會建立跨解決方案的相依性，並在稍後導致目標環境中的解決方案升級或刪除問題。
- 只使用一個解決方案發行者。 解決方案發行者擁有受控解決方案的元件，而且稍後無法變更其關聯。 例如，如果自訂資料表是透過發行者 X 的解決方案 A 匯入為受控，您稍後就無法將該資料表移至發行者 Y 的解決方案 B。唯一的選項是刪除資料表、升級解決方案 A 以從目標系統移除資料表，然後使用發行者 Y 在解決方案 B 中重新建立資料表，並匯入解決方案 B。此程式會導致儲存在自訂資料表中的所有資料遺失，除非事先移轉。
- 避免在解決方案之間建立相依性。 相依性會強制匯入順序，並可能造成問題。 例如，如果您有一個資料表解決方案和另一個雲端流程解決方案，並且某個流程依賴於一個自訂資料行，那麼在開發環境中，它會運作正常，因為該資料行已存在。 不過，如果只將雲端流程解決方案匯入目標環境，則匯入程序可能無法辨識自訂資料行的相依性。 因此，流程解決方案會成功安裝，但流程本身無法運作。 其他資訊： 多個解決方案所建立的相依性範例
多個解決方案所建立的相依性範例
- 應用程式功能區。 當多個解決方案修改相同應用程式的應用程式功能區或網站地圖時。
- 外掛程式或雲端流程。 如果外掛程式或流程在自訂欄上觸發或更新自訂表格，則物件取決於這些自訂表格。
- 安全角色。 當自訂資料表存在時，資訊保護角色通常會相依於這些資料表來進行使用者存取。
具有專用開發環境的多種解決方案
此策略涉及在各個專屬的 Dataverse 開發環境中開發每個非受控解決方案。 此策略通常用於模組化架構，例如，不同的應用程式 （例如銷售、客戶服務或現場服務） 是獨立建置和維護的。 包含常見元件 （例如，帳戶和連絡人資料表） 的基本解決方案會建立，並將其部署為受管理解決方案，部署到每個應用程式特定的開發環境中。 然後，每個應用程式都有自己的非託管解決方案，分層在基底託管解決方案之上，允許團隊在不改變基底基礎的情況下擴展功能。
推薦用於：
- 大型企業項目。
- 具有多個開發人員或合作夥伴的團隊
- 需要嚴格管理和 CI/CD 管線的情境。
| 優勢 | 劣勢 |
|---|---|
| 通過添加或更新模塊，更輕鬆地成長和演變您的系統，而不影響其他模塊。 | 更高的基礎設施和維護開銷。 |
| 多個團隊可以在不同的模組上並行工作，而不會與彼此的變更發生衝突。 | 需要強大的環境策略和治理。 |
| 更容易實施自動化測試和 DevOps 實踐。 | 更複雜的部署。 |
| 較小的解決方案部署速度較快，尤其是在 CI/CD 管線中，如果您只需要部署特定應用程式。 | |
| 當變更隔離到特定模組時，錯誤或回歸更容易追蹤。 |
如何建置解決方案分層
Note
在下列步驟中建立解決方案之前，請針對環境中的所有解決方案使用相同的發行者。 其他資訊：解決方案發行者
- 在「基底」開發環境中，您的基底解決方案具有常見的非受控資料表，而沒有其他資料表。 然後將此解決方案匯出為已管理版本。
- 您可以為擴充功能或「應用程式」層設定第二個開發環境，該環境稍後將位於基礎層之上。
- 您可以將受管理基礎層匯入應用程式層開發環境，並為應用程式層建立非受管理解決方案。
- 您現在可以將其他資料表、資料行、資料表關聯性、外掛程式、流程等新增至特定的「應用程式」解決方案，以擴充資料模型。 然後，將應用程式解決方案匯出為受管理的解決方案。 請注意，應用程式解決方案仍相依於基礎層解決方案，但以這種方式管理多個解決方案是更好的方法。 請考慮先前提到的依賴自訂欄位的流程的範例。 在大多數情況下，自訂資料行和流程都位於相同的應用程式解決方案中。 即使自訂欄位是基礎解決方案的一部分，您也必須先完成並部署該基礎解決方案為已管理，否則應用程式解決方案內的流程甚至無法建立。
- 在您的生產環境中，您可以匯入受管理的基礎層，然後匯入受管理的應用程式層。 這會在環境中建立兩個受管理層，並在受管理解決方案之間建立明確的相依性。
- 重複這個模式，以擁有您需要維護的尽可能多的不同解決方案。 雖然我們建議您儘量維持少量的解決方案，以確保您的解決方案分層易於管理。