解決方案封裝工具可與任何原始檔控制系統一起使用。 將解決方案 .zip 檔案解壓縮到資料夾後，新增並提交檔案到原始檔控制系統。 這些檔案接著就可以在其他電腦上同步處理，檔案可在該電腦中壓縮成完全相同的新解決方案 .zip 檔案。
在使用提取的元件檔案進行原始檔控制管理時，一個重要的考量是將所有的檔案加入至原始檔控制可能會造成不必要的重複。 前往解決方案元件檔案參考，以了解為每種元件類型產生了哪些檔案，以及建議在原始檔控制中使用哪些檔案。
解決方案需要進一步自訂和變更時，開發人員應透過現有方式編輯或自訂元件、重新匯出以建立 .zip 檔案，然後將解決方案檔案解壓縮至相同的資料夾。
Important
除了何時編輯自訂檔案中所述的區段以外，不支援手動編輯解壓縮的元件檔案和 .zip 檔案。
當解決方案封裝工具解壓縮元件檔案時，不會覆寫名稱相同的現有元件檔案 (如果檔案內容完全相同的話)。 此外，該工具尊重元件檔案的唯讀屬性，並在主控台視窗中發出警告，提示特定檔案未寫入。 透過這種保護，使用者能夠從原始檔控制中檢出正在變更的最少文件集。
/clobber 參數可用來避開限制，允許對唯讀檔案進行寫入或刪除。
/allowWrite 參數可用來評估解壓縮作業有哪些影響，實際上不會造成檔案寫入或刪除。 使用 /allowWrite 參數與詳細日誌記錄相結合是有效的。
從版本控制擷取出最小的一組檔案後，開發人員可以像處理任何其他類型的源代碼檔案一樣，將修改過的檔案提交回版本控制。
原始碼控制檔案格式
解決方案包裝工具支援兩種解壓元件檔案的檔案格式。 一開始選擇正確的格式，可以避免之後還得遷移儲存庫結構。
| XML 格式（舊有） | YAML 原始碼控制格式 | |
|---|---|---|
| 解決方案清單 | Other\Solution.xml + Other\Customizations.xml |
solutions/<name>/solution.yml 並支援 YAML 檔案 |
| 可讀性 | Verbose XML | 精簡 YAML — 更易閱讀與檢視 |
| Git 品質差異 | 大型 XML 差異 | 極簡且聚焦的差異 |
| 多解方案庫 | 不支援 | 支援 — 多個解決方案共用一個資料夾 |
| Canvas 應用程式（.msapp） | 不支援 | 支援 |
| 現代化流程 | 不支援 | 支援 |
| 原生 Git 整合 | 未使用 | 一直用 — Git 整合總是寫 YAML |
何時使用 YAML 格式： 對於所有新專案，以及你使用原生 Dataverse Git 整合時， YAML 格式具備向前相容性，並產生更乾淨的變更歷史。
何時使用 XML 格式： 只有在使用已使用 XML 格式的現有軟體庫，或使用不支援 YAML 的舊有工具時才會這樣。
Note
當你在 Power Apps 中使用 Git 整合提交解決方案時，它們總是以 YAML 原始碼控制格式儲存。 若要手動打包或解包該來源資料，使用 SolutionPackager 或 pac solution pack，資料夾必須遵循 YAML 資料夾結構。 更多資訊： SolutionPackager 工具 — 原始碼控制檔案格式
團隊開發
當多個開發人員正在使用相同的解決方案元件時，若兩個開發人員的變更造成單一檔案的變更，則可能會發生衝突。 藉由分解每個可編輯元件或子元件至不同的檔案，此發生次數已降至最低。 請考慮下列範例。
開發人員 A 和 B 正在處理同一個解決方案。
在獨立電腦上，他們會從來源控制取得最新的解決方案來源，打包並將未管理的解決方案 .zip 檔案匯入獨立的 Microsoft Dataverse 組織。
開發者 A 自訂「活躍聯絡人」系統視圖及聯絡實體的主表單。
開發人員 B 自訂了帳戶實體的主表單，並變更了「連絡人尋找檢視」。
這兩個開發人員都會匯出未受管理的解決方案 .zip 檔案並解壓縮。
開發者 A 需要檢出一個「聯絡人主表單」的檔案以及一個「活躍聯絡人檢視」的檔案。
開發人員 B 需要檢出一個「帳戶」主表單的檔案和一個「連絡人尋找檢視」的檔案。
由於各自的變更涉及不同的文件，因此兩位開發人員可以按任意順序提交。
在兩次提交完成後，他們可重複步驟 #2，接著在他們各自的組織中繼續進行進一步的變更。 他們每人都擁有兩組變更，而且他們原有的工作沒有被覆蓋。
只有變更不同的檔案時，前一個範例才能運作。 獨立自訂需要在單一檔案內進行變更是不可避免的。 根據前面的例子，假設開發者 B 正在自訂「活躍聯絡人」視圖，而開發者 A 也正在同時自訂。 在此新範例中，事件順序變成重要。 這裡完整地描述了解決這個困境的正確過程。
開發人員 A 和 B 正在處理同一個解決方案。
在獨立電腦上，他們都會從原始檔控制取得解決方案的最新原始檔、進行壓縮，然後將未受管理的解決方案 .zip 檔案匯入至獨立組織。
開發者 A 自訂「活躍聯絡人」系統視圖及聯絡人表的主表單。
開發人員 B 自訂了帳戶資料表的主表單，並變更了「現行連絡人」。
這兩個開發人員都會匯出未受管理的解決方案 .zip 檔案並解壓縮。
開發者 A 需要檢出一個「聯絡人主表單」的檔案以及一個「活躍聯絡人檢視」的檔案。
開發者 B 需要檢出一個帳號主表單的檔案，以及一個「活躍聯絡人」視圖的檔案。
開發人員 A 先準備就緒。
在開發人員 A 提交到版本控制系統之前，他們必須取得最新的原始檔，以確保先前的簽入未與其變更衝突。
沒有衝突，因此開發人員 A 可以提交。
開發人員 B 將在開發人員 A 之後準備就緒。
在開發人員 B 提交之前，他必須取得最新的原始碼，以確保之前的簽入不會與他的變更發生衝突。
有衝突是因為「Active Contacts」的檔案自開發者 B 上次提取最新的檔案資源後已被修改。
開發人員 B 必須協調衝突。 正在使用的原始檔控制系統的功能可能會輔助此過程；否則，下列選擇都很可行。
開發人員 B，透過原始檔控制歷程記錄 (如果有)，可以觀察到開發人員 A 進行之前的變更。 透過直接通訊，他們可討論每個變更。 然後開發人員 B 只需要以同意的解決方案來更新組織。 開發人員 B 接著匯出，擷取，並覆寫衝突檔案並送出。
允許版本控制覆寫本機檔案。 開發人員 B 將解決方案打包並匯入到其組織中，隨後評估檢視狀態，並根據需要進行重新調整。 接下來，開發人員 B 可能會匯出、擷取並覆寫有衝突的檔案。
如果認為先前的變更沒有必要，開發人員 B 允許其檔案副本覆蓋版本控制中的版本並提交。
無論是在共用環境還是獨立環境中工作，Dataverse 解決方案的團隊開發都要求那些積極致力於共同解決方案的人員了解其他人的工作。 解決方案封裝工具並不能完全消除這種需求，但它能夠在原始檔控制層級輕鬆合併不衝突的變更，並主動醒目顯示發生衝突的簡潔元件。
接下來的部分是與團隊一起開發時在原始檔控制中有效使用解決方案封裝工具的通用流程。 它們在獨立環境或共用開發環境中同樣有效，但在共用環境中，匯出和提取自然包括解決方案中存在的所有變更，而不僅僅是執行匯出的開發人員所做的變更。 類似地，當匯入解決方案 .zip 檔案時，也會自然發生覆寫所有元件的行為。
建立解決方案
此過程確定了首次建立解決方案時使用的典型步驟。
在具有 Dataverse 的乾淨環境中建立解決方案，然後根據需要新增或建立元件。
當您準備好辦理登機手續時，請按照以下步驟操作。
匯出未受管理的解決方案。
使用解決方案封裝工具，將解決方案提取到元件檔案中。
從這些抽取的元件檔案中，將必要的檔案新增至版本控制系統。
將這些變更送出至版本控制。
修改解決方案
下列程序識別修改現有解決方案時使用的一般步驟。
同步處理或取得最新的解決方案元件檔案來源。
使用解決方案封裝程式工具，將元件檔案封裝到非受控解決方案 .zip 檔案中。
將非受控解決方案檔案匯入環境。
視需要自訂及編輯解決方案。
當您準備將變更提交至原始檔控制時，請按照下列步驟操作。
匯出未受管理的解決方案。
使用解決方案封裝工具，將匯出的解決方案提取到元件檔案中。
同步或從版本控制系統獲取最新的原始碼。
調解如果存在任何衝突。
將變更提交到版本控制。
步驟 2 和 3 必須先完成，才能在開發團隊中進行進一步的自訂設定。 在步驟 5 中，必須先完成步驟 b，再完成步驟 c。