Power BI 實作規劃：開發內容和管理變更
注意
本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介，請參閱 Power BI 實作規劃。
本文可協助您在管理內容生命週期時開發內容及管理變更。 本文的主要目標讀者為：
- 卓越中心 (COE) 和 BI 小組：這類小組負責監督組織中的 Power BI。 這些小組包含決定如何管理 Power BI 內容生命週期的決策者。 這些小組也包含各種角色，例如發佈管理員 (負責處理內容發佈生命週期) 或工程師 (負責建立及管理有效使用及支援生命週期管理所需的元件)。
- 內容建立者和內容擁有者：建立要發佈至 Fabric 入口網站以與其他人員共用內容的使用者。 這些人員負責管理所建立 Power BI 內容的生命週期。
生命週期管理是您用於處理內容的程序和做法，涵蓋內容的建立到最終淘汰。 在生命週期管理的第一個階段中，您要規劃及設計內容，這些內容涉及解決方案規劃和制定影響生命週期管理方法的重要決策。 在第二個階段中，您要開發內容及管理變更。
在內容變更生命週期中管理內容變更很重要，可確保內容建立者之間有效的共同作業，並穩定且一致地將內容傳遞至取用者。
下圖描述 Power BI 內容的生命週期，其中醒目提示您在其中開發內容及管理變更的第二階段。
注意
如需內容生命週期管理的概觀，請參閱本系列的第一篇文章。
提示
本文著重於重要決策和考量，協助您在整個生命週期中開發內容及管理變更。 如需如何開發內容及管理變更的詳細資訊指引，請參閱：
- 什麼是 Microsoft Fabric 中的生命週期管理？：本文提供 Fabric Git 整合及部署管線的技術簡介和教學課程。
- 生命週期管理最佳做法：本文包含使用 Fabric 和 Power BI 生命週期管理功能來開發內容及管理變更的實用秘訣和指引。
- Power BI Desktop OneDrive 和 SharePoint 整合：當您使用 .pbix 檔案執行版本控制時，本文包含使用及儲存至公司或學校用 OneDrive 或 SharePoint 的選項概觀。
- 在 Azure Repos 中開始使用 Git：這一系列文章包含使用 Azure Repos 中的 Git 存放庫執行原始檔控制的實用秘訣、教學課程和指引。
內容建立者和擁有者應該使用版本控制來管理內容變更。 版本控制是在中央存放庫中管理檔案或程式碼變更的做法。 這種做法有助於提升共同作業和內容管理的效率。
版本控制的其他優點包括能夠：
- 合併來自多個內容建立者的變更，並處理合併衝突。
- 識別哪些內容已變更，以及該內容中變更的部分。
- 將內容變更連結至特定工作項目。
- 將變更分組為具有版本歷程記錄的不同版本。
- 復原變更或整個內容版本。
提示
建議您盡可能針對您所建立的所有內容使用版本控制。 使用版本控制對於內容建立者和取用者都有顯著的好處，並降低因檔案遺失或無法復原變更而中斷的風險。
設定版本控制的第一個步驟是決定您開發內容的方式。
決定開發內容的方式
視您撰寫內容的方式而定，您將針對管理內容的方式做出不同的決策。 例如，針對 Power BI 報表和語意模型，相較於 Power BI Desktop 專案 (.pbip) 格式，Power BI Desktop (.pbix) 檔案的版本控制選項較少。 這是因為 .pbix 檔案是二進位格式，而 .pbip 格式則包含以文字為基礎的人類可讀取內容和中繼資料。 擁有人類可讀取的內容和中繼資料，可讓您更輕鬆地使用原始檔控制來追蹤模型和報表變更。 原始檔控制是在您檢視及管理其程式碼和中繼資料內容內的變更時。
提示
使用 Power BI Desktop 開發語意模型和報表時，建議您使用 .pbip 檔案，而不是 .pbix 檔案。 使用 XMLA 工具開發語意模型時，建議您使用表格式模型定義語言 (TMDL) 格式，而不是 .bim 檔案。
.pbip 和 TMDL 格式支援更容易追蹤及合併物件層級變更。 這表示您可以檢視及管理個別對象的變更，例如 DAX 量值或資料表。
Power BI Desktop
您可以使用 Power BI Desktop 來建立語意模型或報表，您可以將其儲存為 .pbix 或 .pbip 檔案。 當您使用 Power BI Desktop 時，也可以使用其他自訂內容檔案。使用 Power BI Desktop 建立內容時，您應該制定的一些重要決策包括：
- 要使用的檔案格式：您可以將內容儲存為 .pbix 或 .pbip 檔案。 例如，Git 整合需要您使用 .pbip 檔案，自助建立者可能會發現在 Teams、SharePoint 或 OneDrive 中管理及維護 .pbix 檔案更簡單。
- 如何管理自訂內容：您可以將主題、自訂視覺效果或影像新增至 Power BI Desktop 檔案，這可能需要不同生命週期管理的考量。 例如，當內容建立者製作自己的自訂視覺效果時，他們應該在個別檔案中儲存及管理視覺效果定義。
- 如何管理預覽功能：您可以加入 Power BI Desktop 中的預覽功能或設定，這會改變內容，以及您使用此功能的方式。 例如，您可以採取其他步驟來驗證使用預覽功能的內容。
Web 撰寫
某些內容 (例如資料流程、儀表板和計分卡) 只能在 Fabric 入口網站中建立。 您也可以在 Fabric 入口網站或使用本機工具中建立或修改某些內容，例如語意模型、報表和編頁報表。 使用 Web 撰寫建立內容時，您應該制定的一些重要決策包括：
- 如何管理變更：您可以使用 Web 撰寫對許多項目類型進行變更，但這些變更可能會立即儲存，並覆寫舊版。 例如，如果您要與其他人共同作業，可能要避免在共用項目上進行 Web 撰寫，而是改用您自己的複本。
- 如何擷取內容備份：您可以使用 Web 撰寫來建立報表或語意模型等內容，但這些項目無法下載到本機 .pbix 檔案。 例如，您可以選擇擷取及儲存其中繼資料來備份此內容。
提示
開發資料流程和計分卡時，建議您擷取項目定義來管理變更並儲存備份。 您可以使用 Fabric REST API 將資料流程和計分卡擷取自動化。 具體來說，您可以分別使用取得資料流程和取得計分卡端點。
警告
某些內容 (例如儀表板) 沒有擷取定義的選項。 針對此內容，您無法輕鬆地追蹤變更或擷取備份。
其他工具
您可以使用其他工具來建立或管理特定類型的內容。 這些工具可能會提供額外的優點、更適合您的工作流程，或需要管理特定功能或內容類型。 您可以使用其他 Microsoft 工具或第三方工具來建立及管理內容。 您可以用來建立或管理內容的其他工具如下所示。
- Visual Studio 或 Visual Studio Code：開發人員建立及管理語意模型或 Fabric 筆記本的整合式開發環境。 透過 Visual Studio 和 Visual Studio Code，開發人員也可以認可本機變更並推送至遠端存放庫，來執行原始檔控制管理 (SCM)。
- 表格式編輯器：開發及管理語意模型的第三方工具。
- Excel：樞紐分析表和即時連線資料表的用戶端工具，可搭配語意模型使用。
- Power BI Report Builder：用來建立編頁報表 (.rdl) 檔案的傳統型應用程式。
使用其他工具建立內容時，您應該制定的一些重要決策包括：
- 如何管理授權：其他工具可能需要您應管理的其他授權。
- 如何發佈內容：其他工具可能需要額外的步驟來發佈內容，例如使用 XMLA 端點或 Power BI REST API。
一旦您決定建立內容的方式後，接下來必須選擇要在開發內容時發佈及測試內容的位置。
決定設定及使用工作區的方式
開發內容時，您應該使用多個工作區 (或階段) 來分隔組織所使用的生產內容與開發或驗證的內容。 針對您的內容使用個別工作區有幾個優點：
- 您可以開發及測試內容，而不會影響目前使用中的內容。 這可避免在生產環境中可能造成非預期中斷內容的變更。
- 您可以使用個別的資源來開發及測試內容，例如使用個別的資料閘道或 Fabric 容量。 這可避免用於開發和測試的資源中斷生產工作負載，導致資料重新整理或報表變慢。
- 您可以針對每個階段建立更結構化的程序，以開發、測試及發行內容。 這可協助您提升生產力。
在 Fabric 和 Power BI 中，建議您使用個別的 Fabric 工作區，如租用戶層級和工作區層級規劃文章中所述。
重要
使用個別環境是確保內容生命週期管理方法成功的重要步驟。
使用 Fabric 工作區來分隔環境的方式有很多種。 一般而言，除了本機環境之外，您還可以使用兩個以上的工作區來管理其生命週期中的內容。
當您規劃如何在此內容的整個生命週期中使用個別工作區時，請回答下列問題：
- 您需要多少個工作區？
- 您是否要依項目類型分隔工作區？
- 誰可以存取每個工作區？
- 工作區是否屬於 Fabric 部署管線，或者您是否會使用其他方法來協調部署，例如使用 Azure Pipelines？
- 您要如何管理跨工作區發佈？ 例如，您是否需要確保報表測試工作區中的報表會連線到個別測試工作區中資料項的語意模型？
- 您是否也需要針對生產工作區中的項目使用不同的支持資源，例如個別內部部署的資料閘道叢集？
下列各節提供不同方法的高階概觀，供您針對個別工作區加速生命週期管理。
注意
下列各節著重於如何設定及使用個別工作區。 您可以使用下列四種方法之一，將內容部署至這些工作區：
- 從 Power BI Desktop 發佈。
- 使用 Fabric 部署管線從另一個工作區部署內容。
- 使用 Git 整合從遠端 Git 存放庫同步處理內容。
- 使用 Fabric REST API、Power BI REST API 或 XMLA 端點，以程式設計方式部署內容。
如需這些部署內容方法的詳細資訊，請參閱本系列稍後的階段 4：部署內容。
測試和生產工作區
當您提供對組織而言不重要的較簡單內容時，兩個工作區通常就足夠了。 在此案例中，內容建立者通常在同一個項目上具有有限的共同作業，並在本機開發內容。
下圖描述如何只搭配測試及生產工作區使用個別環境的高階範例。
此圖表描述下列程序和元件，以分隔此方法中的工作區。
| 項目 | 說明 |
|---|---|
 |
內容建立者會在其本機環境中開發內容。 |
 |
準備好時，內容建立者會將內容發佈至測試工作區。 內容建立者可以開發內容，而這些內容只能與 Web 撰寫一起產生，並在測試工作區中執行內容驗證。 |
 |
準備好時，內容建立者會將內容部署至生產工作區。 在生產工作區中，內容建立者會發佈 Power BI 應用程式或從工作區共用內容來發佈內容。 |
注意
有許多不同的方式可以設定及使用個別工作區，並在這些工作區之間部署內容。 不過，建議您不要執行本機開發，然後將內容直接發佈至生產工作區。 這可能會導致可預防的中斷和錯誤。
開發、測試和生產工作區
傳遞業務關鍵性內容時，您通常會使用三個或多個不同的工作區。 在此案例中，內容建立者通常會在包含最新版解決方案的其他開發工作區中共同作業。
下圖描述如何搭配開發、測試和生產工作區使用個別環境的高階範例。
此圖表描述下列程序和元件，以分隔此方法中的工作區。
| 項目 | 說明 |
|---|---|
|
內容建立者會在其本機環境中開發內容。 |
|
準備好時，內容建立者會將內容發佈至開發工作區。 在開發工作區中，內容建立者可以開發內容，而這些內容只能與 Web 撰寫一起產生。 內容建立者也可以驗證開發工作區中的內容。 |
|
準備好時，內容建立者會將內容部署至測試工作區。 在測試工作區中，使用者會在工作區或應用程式中驗證內容。 |
 |
準備好時，內容建立者會將內容部署至生產工作區。 在生產工作區中，內容建立者會發佈 Power BI 應用程式或從工作區共用內容來發佈內容。 |
注意
您最多可以使用十個不同的環境搭配部署管線。 例如，您可能想要在測試與生產環境之間有一個預先生產環境，其特別適用於特殊類型的驗證，例如效能測試。
具有 Git 整合的私人工作區
傳遞業務關鍵性內容時，每個開發人員也可以使用自己的私人工作區進行開發。 在此案例中，私人工作區可讓內容建立者在 Fabric 入口網站中測試內容，或使用排程重新整理之類的功能，而不會對開發小組中的其他人員造成中斷的風險。 內容建立者也可以在這裡開發 Fabric 入口網站中的內容，例如資料流程。 當您同時使用 Git 整合與 Azure DevOps 來管理內容變更時，私人工作區是不錯的選擇。
注意
Azure DevOps 是一套與 Power BI 和 Fabric 整合的服務，可協助您規劃和協調內容生命週期管理。 以這種方式使用 Azure DevOps 時，您通常會利用下列服務：
- Azure Repos：可讓您建立及使用遠端 Git 存放庫，這是用來追蹤和管理內容變更的遠端儲存位置。
- Azure Pipelines：可讓您建立和使用一組自動化工作來處理、測試及部署遠端存放庫的內容至工作區。
- Azure Test Plans：可讓您設計測試來驗證解決方案，並將品質控制與 Azure Pipelines 一起自動化。
- Azure Boards：可讓您使用面板來追蹤工作和計劃做為工作項目，以及連結或參照來自其他 Azure DevOps 服務的工作項目。
- Azure Wiki：讓您與其小組共用資訊，以了解並參與內容。
下圖描述如何透過私人工作區搭配 Git 整合，使用個別環境的高階範例。
注意
此圖描述個別開發人員在將變更合併到主要分支之前，先處理解決方案的個別分支 (分支一和分支二)。 這是 Git 分支策略的簡化描述，說明開發人員如何將其變更與遠端 Git 存放庫整合，並受益於 Fabric 中的 Git 整合。
此圖表描述下列程序和元件，以分隔此方法中的工作區。
| 項目 | 說明 |
|---|---|
|
每個內容建立者都會在自己的本機環境中開發內容。 |
|
準備好時，內容建立者會認可其變更並推送至遠端存放庫，例如 Azure Repos Git 存放庫。 |
|
在遠端 Git 存放庫中，內容建立者會使用原始檔控制來追蹤及管理內容變更，以及分支和合併內容，以加速共同作業。 |
|
內容建立者會同步遠端存放庫的分支與私人工作區。 同步處理之後，建立者認可並推送至分支的最新變更會顯示在該私人工作區中。 不同的內容建立者會在進行變更時，自行處理個別分支。 |
 |
在私人工作區中，內容建立者可以使用 Web 撰寫來開發內容，並驗證自己的變更。 當內容建立者認可這些變更並從工作區推送這些變更時，Web 撰寫對內容所做的內容變更可以與 Git 存放庫中的分支同步。 不同的內容建立者會在自己的個別私人工作區中工作。 |
 |
準備好時，內容建立者會執行提取要求，將其變更合併至解決方案的主要分支。 |
 |
合併變更之後，主要分支會與開發工作區同步。 |
 |
在開發工作區中，內容建立者可以開發 Fabric Git 整合所不支援的內容，例如儀表板。 內容建立者也會驗證包含所有最新變更的整合式解決方案。 |
 |
準備好時，內容建立者會將內容部署至測試工作區。 在測試工作區中，使用者會執行內容的使用者驗收測試。 |
 |
準備好時，內容建立者會將內容部署至生產工作區。 在生產工作區中，內容建立者會發佈 Power BI 應用程式或從工作區共用內容來發佈內容。 |
支援工作區的資源
當您使用不同的環境時，也應該考慮這對您在這些環境中使用的各種支援資源有何影響。 針對這些支援的資源，請考慮您是否也需要將其分隔成相同數目的階段，或您將如何協調其在這些環境中的使用方式。
- 閘道：請考慮針對生產工作負載使用個別的內部部署資料閘道叢集和 VNet 閘道。 這有利於防止中斷，也有助於確保需要更新這些閘道時的可用時間。
- 應用程式：請考慮針對測試和生產工作區擁有個別的應用程式。 您無法在階段之間部署或複製應用程式。 測試工作區中的應用程式旨在協助您在將變更部署至生產工作區之前，先測試內容和應用程式體驗。 生產工作區中的應用程式旨在以結構化和體驗將內容傳遞給使用者。
- Azure DevOps：如果您想要使用 Azure DevOps 來共同作業及協調原始檔控制和部署，請考慮如何使用分支和 Azure Pipelines 在這些環境之間部署內容。 如需使用 Azure Pipelines 部署內容的詳細資訊，請參閱階段 4：部署內容。
決定如何設定及使用工作區之後，下一個步驟是決定如何執行版本控制來追蹤及管理內容變更。
決定您將使用版本控制的方式
在 Power BI 中，您可以使用 SharePoint/OneDrive，或使用遠端 Git 存放庫 (例如 Azure Repos) 來執行版本控制，這是 Azure DevOps 的元件。 在這兩種方法中，您會將本機內容檔案新增至遠端儲存位置，以協助追蹤及管理變更。 建議您只針對較小型和較簡單的專案使用 SharePoint 或 OneDrive，因為其缺少支援較大型或更複雜案例的功能和強固性。
以下是一些一般考慮，可協助您設定及使用版本控制。
- 警示：當其他人員新增、移除或修改重要檔案時，您應該設定警示。
- 範圍：明確定義遠端儲存位置的範圍。 理想情況下，遠端儲存位置的範圍會與您用來將內容傳遞給取用者之下游工作區和應用程式的範圍相同。
- 存取：在設定遠端儲存位置存取權時，所使用的權限模型應與為部署管線權限和工作區角色所設定的權限模型類似。 內容建立者需要存取遠端儲存位置。
- 文件：將文字檔新增至遠端儲存位置，以描述遠端儲存位置及其用途、擁有權、存取和定義的程序。
下列各節說明每個方法和重要考量，以決定您應該使用哪一種方法和重要考量。
使用 SharePoint 或公司或學校用 OneDrive 進行版本控制
SharePoint 具有檔案的內建版本控制。 內容建立者可以在本機開發語意模型或報表，且其變更會同步處理至 SharePoint 或公司或學校用 OneDrive 文件庫。
提示
在較簡單、較小型的案例 (例如自助內容發佈) 中，只針對版本控制使用 SharePoint 或 OneDrive。 針對較大型或較複雜的案例，您應該考慮使用遠端 Git 存放庫來執行原始檔控制。
下圖描述如何使用 SharePoint 或 OneDrive 執行版本控制的高階概觀。
此圖描述下列程序和元件。
| 項目 | 說明 |
|---|---|
|
內容建立者會在其本機環境中開發語意模型和報表，並將這些模型和報表儲存為 .pbix 檔案。 |
|
準備好時，內容建立者會儲存其變更，這些變更會同步處理至遠端 SharePoint 或公司或學校用 OneDrive 程式庫。 |
|
在遠端程式庫中，內容建立者會追蹤檔案層級的變更，以利版本控制。 |
|
內容建立者可以將已發佈的語意模型或報表連結至 .pbix 檔案，以利 OneDrive 重新整理。 OneDrive 重新整理會每小時自動發佈內容變更。 |
|
在 [Fabric] 工作區中，內容建立者會在 OneDrive 重新整理完成之後看到 Power BI 內容的變更。 |
重要
您只能使用包含語意模型或報表的 SharePoint 或 Power BI Desktop 檔案用 OneDrive 來執行版本控制。 您無法針對資料流程等其他 Power BI 項目類型，或筆記本等 Fabric 項目類型，使用 SharePoint 或 OneDrive 輕鬆執行版本控制。 針對這些其他項目類型，您應該使用遠端 Git 存放庫 (例如 Azure Repos) 來執行版本控制。
為摘要說明，內容建立者可以連結已發佈的語意模型或報表到儲存在 SharePoint 或工作或學校用 OneDrive 程式庫。 使用此方法時，內容建立者不必再發佈語意模型來查看變更。 相反地，變更會在自動 OneDrive 重新整理之後顯示，會每小時發生。 雖然很方便，但這種方法會伴隨一些考量，因此無法輕易地反轉。
雖然很容易設定及管理，但使用 SharePoint 或 OneDrive 的版本控制有更多限制。 例如，您無法檢視內容中的變更，也無法比較版本。 此外，您無法設定更複雜的程序來管理這些變更 (如本文稍後所述的分支或提取要求)。
請考慮使用 SharePoint 或 OneDrive 來追蹤及管理下列案例中的變更：
- 內容只包含儲存為 .pbix 檔案的語意模型或報表。
- 自助使用者會建立及管理內容。
- 內容建立者會使用 Microsoft Teams 來共同作業。
- 內容建立者不熟悉 Git 和原始檔控制管理。
- 內容建立者會以有限的複雜度和共同作業來管理單一項目。
- .pbix 檔案已套用敏感度標籤，以加密其內容。
請避免使用 SharePoint 或 OneDrive 來追蹤及管理下列案例中的變更：
- 內容是由語意模型和報表以外的項目類型所組成。
- 內容的範圍很複雜或很龐大。
- 內容建立者必須同時在同一個項目上共同作業。
下列各節說明搭配 Power BI 使用 SharePoint 或 OneDrive 有效地使用版本控制的其他考量。
Microsoft Teams 整合
如果內容建立者將文件庫用於其共同作業，則您可以使用 Microsoft Teams 中的文件庫。 文件庫是 SharePoint 網站，並使用文件庫 (而不是個別的 SharePoint 網站或 OneDrive 資料夾)，可確保集中內容、檔案和共同作業。
簽入與簽出檔案
您應該簽出您正在處理的檔案，以避免可能發生的變更衝突。 一旦變更完成後，請使用描述變更的註解簽入檔案。 當您使用 SharePoint 或公司或學校用 OneDrive 進行版本控制時，簽入和簽出檔案可協助您改善內容建立者之間的共同作業。 如果您使用多個內容建立者簽入和簽出檔案，則可以修改 SharePoint 網站程式庫，以檢視上次更新和上次簽入的註解。
版本歷程記錄
請務必將內容備份到個別的位置，以防 SharePoint 網站文件庫發生非預期的中斷。 您也應該設定 SharePoint 網站中保留的版本數目限制，並刪除舊版本。 這可確保版本歷程記錄仍然有意義，且不會佔用太多空間。
如需更複雜的版本控制，您可以將檔案儲存在遠端存放庫中，例如 Azure Repos，並使用原始檔控制來管理變更。
使用遠端 Git 存放庫進行原始檔控制
遠端 Git 存放庫可協助原始檔控制，讓內容建立者有更多選項來追蹤及管理變更。 簡而言之，內容建立者可以在本機或 Power BI 服務中開發內容，然後認可這些變更並將變更推送至遠端 Git 存放庫 (例如 Azure Repos)
注意
您也可以執行內容的原始檔控制，而不需使用 Git 整合。 在此案例中，您仍會追蹤及管理遠端 Git 存放庫中的內容變更，但您會使用 REST API 或 XMLA 讀取/寫入端點來部署內容。 如需這些部署內容方法的詳細資訊，請參閱階段 4：部署內容。
下圖描述如何執行原始檔控制的高階概觀
此圖描述下列程序和元件。
| 項目 | 說明 |
|---|---|
|
內容建立者會在其本機環境中開發語意模型和報表，並將這些模型和報表儲存為 .pbip 檔案。 內容建立者也可以開發語意模型並儲存模型中繼資料。 |
|
準備好時，內容建立者會儲存其變更，而這些變更會定期認可並推送至遠端 Git 存放庫。 |
|
在遠端 Git 存放庫中，內容建立者會追蹤物件層級的變更，以利版本控制。 內容建立者也可以建立分支來處理內容，並使用提取要求將其變更合併到單一分支。 |
|
內容建立者可以使用 Git 整合，從遠端存放庫同步處理內容。 他們也可以使用其他方法 (例如 Azure Pipelines 與 REST API) 來部署內容。 |
|
在 [Fabric] 工作區中，內容建立者在同步或部署完成之後，會看到 Power BI 內容的變更。 內容建立者可以撰寫內容，例如工作區中的資料流程或筆記本。 如果他們使用 Git 整合，內容建立者會將此工作區連結至遠端存放庫的特定分支。 |
|
內容建立者可以使用 Git 整合，將從工作區認可變更並推送至遠端存放庫。 這些變更可以匯入工作區中所撰寫支援內容的項目定義，例如資料流程和筆記本。 |
總而言之，內容建立者會將 .pbip 檔案、中繼資料檔案和文件儲存在中央 Azure Repos 遠端存放庫中。 這些檔案由技術擁有者策展。 當內容建立者開發解決方案時，技術擁有者負責管理解決方案並檢閱變更，以及將其合併成單一解決方案。 相較於 SharePoint 和 OneDrive，Azure Repos 提供更複雜的選項來追蹤及管理變更。 維護精心策展且有記載的存放庫非常重要，因為其為所有內容和共同作業的基礎。
請考慮使用原始檔控制來追蹤及管理下列案例中的變更：
- 集中式或分散式小組會建立及管理內容。
- 內容建立者會使用 Azure DevOps 共同作業。
- 內容建立者熟悉 Git、原始檔控制管理或 DataOps 原則。
- 內容建立者會管理複雜或重要的內容，或預期內容會在複雜度和重要性上有所調整和成長。
以下是一些必要條件和考量，可協助您有效地搭配 Azure DevOps 使用原始檔控制。
- Git：若要認可變更並推送至遠端存放庫，內容建立者必須下載並安裝 Git。 Git 是一種分散式版本控制系統，可追蹤檔案中的變更。 若要了解 Git 的基本概念，請參閱什麼是 Git？。
- 工具：若要使用 Git，內容建立者必須使用命令列介面 (CLI) 或 SCM 的圖形使用者介面 (GUI) 用戶端，例如 Visual Studio 或 Visual Studio Code。
- 授權和權限：若要建立及使用 Azure Repos Git 存放庫，內容建立者必須具有下列項目：
- Fabric Git 整合：若要同步遠端存放庫中的內容與 Microsoft Fabric 工作區，內容建立者會使用 Fabric Git 整合。 這對於追蹤及管理在 Fabric 入口網站中建立的內容 (例如資料流程) 很重要。
提示
為了協助進行本機開發的原始檔控制，建議您使用 Visual Studio Code 之類的用戶端應用程式。 您可以使用 Power BI Desktop 來開發內容，然後使用 Visual Studio Code 執行該內容的原始檔控制管理，方法是暫存、認可和推送變更至遠端存放庫。
警告
Fabric Git 整合對於支援的項目和案例有一些限制。 請確定您先驗證 Fabric Git 整合是否符合您的特定案例，還是應該採取不同的方法來實作原始檔控制。
此外，Fabric Git 整合不支援敏感度標籤，且可能會停用具有敏感度標籤的項目。 如果您的內容具有敏感度標籤，您應該規劃如何達成版本控制，同時仍遵守資料外洩防護原則。
搭配 Azure Repos 使用原始檔控制的主要優點是改善內容建立者之間的共同作業，以及有關內容變更和部署的更多自訂和監督。
下圖描述 Azure DevOps 如何啟用與原始檔控制共同作業的高階概觀。
注意
上圖描述如何使用 Azure DevOps 共同作業的一個範例。 選擇最符合您小組需求和工作方式的方法。
此圖會描述下列使用者動作、程序和功能。
| 項目 | 說明 |
|---|---|
|
內容建立者藉由複製包含最新版內容的主要分支來建立新的短期分支。 新分支通常稱為「功能」分支，因為其會用來開發特定功能或修正特定問題。 |
|
內容建立者在開發期間將其變更認可至本機存放庫。 |
|
內容建立者將其變更連結至可在 Azure Boards 中管理的工作項目。 工作項目會描述範圍在其分支內的特定開發、改進或錯誤修正。 |
|
內容建立者定期認可其變更。 準備好時，內容建立者會將其分支發佈至遠端存放庫。 |
|
為了測試其變更，內容建立者將其解決方案部署到針對其開發所隔離的工作區 (此圖未顯示)。 內容建立者也可以使用 Fabric Git 整合，將功能分支同步至工作區。 |
|
內容建立者和內容擁有者在 Azure Wiki 中記載解決方案及其程序，以供整個開發小組檢視。 |
|
準備好時，內容建立者會開啟提取要求，以將功能分支合併至主要分支。 |
|
技術擁有者負責檢閱提取要求並合併變更。 當其核准提取要求時，便會將功能分支合併至主要分支。 |
|
合併成功時，便會觸發使用 Azure Pipeline 將解決方案部署至開發工作區的作業 (此圖未顯示)。 使用 Fabric Git 整合時，主要分支會同步至開發工作區。 |
|
發行管理員執行解決方案的最終檢閱和核准。 此發行核准可防止解決方案在準備好之前就發佈。 在企業內容發佈中，發行管理員通常會規劃和協調內容在測試工作區和生產工作區的發行。 其會與內容建立者、專案關係人和使用者進行協調和通訊。 |
 |
當發行管理員核准發行時，Azure Pipelines 會自動準備解決方案以供部署。 或者，Azure Pipeline 也可以觸發部署管線，以在工作區之間進行內容升階。 |
 |
使用者在測試工作區中測試及驗證內容。 使用 Git 與 Azure Pipelines 的整合來進行部署時，測試工作區不會與任何分支同步。 |
 |
在使用者接受和驗證變更之後，發行管理員會執行解決方案的最終檢閱和核准，以將其部署至生產工作區。 |
 |
使用者檢視發佈至生產工作區的內容。 使用 Git 與 Azure Pipelines 的整合來進行部署時，生產工作區不會與任何分支同步。 |
下列各節說明使用 Azure DevOps 和 Power BI 有效地使用原始檔控制的其他考量。
重要
當您管理 Power BI 內容的生命週期時，有效使用分支、認可、提取要求及合併，對於從原始檔控制中獲得最大受益至關重要。
使用分支
內容建立者會使用「分支策略」來達成共同作業。 分支策略可讓個別內容建立者以隔離的方式在其本機存放庫中工作。 準備好時，其便會將變更合併成遠端存放庫中的單一解決方案。 內容建立者應藉由將分支連結至特定開發、改進或錯誤修正的工作項目，以將其工作範圍限定在分支上。 每個內容建立者都會為其工作範圍建立自己的遠端存放庫分支。 在其本機解決方案上完成的工作會認可並推送至遠端存放庫中的某個分支版本，並附上描述性「認可訊息」。 認可訊息會描述該認可中所進行的變更。
當您使用分支策略來管理 Fabric 內容時，請考慮下列因素。
- 哪些分支內容建立者應該針對自己的工作複製。 例如，如果這些分支是主分支的複製品 (稱為主幹式開發)，或這些分支為其他分支，例如特定已規劃內容版本的發行分支。
- 您是否將使用發行分支將特定工作範圍限定為不同的內容版本。
- 當您使用 Fabric Git 整合時，哪些分支會連線到哪個工作區。
提示
如需如何以最佳方式使用分支策略有效促進共同作業的特定指引和建議，請參閱採用 Git 分支策略。
認可中的批次變更
開發內容時，建立者應該定期將變更暫存成批次 (或群組)。 這些變更應解決解決方案 (例如功能或問題) 的特定工作項目。 準備好時，內容建立者會認可這些暫存變更。
以這種方式批次處理變更有數個優點。
- 其可協助結構開發，並讓內容建立者有機會檢閱及記錄其已分組的變更。
- 其可改善規劃和開發之間的一致性，讓您更輕鬆地連結功能和問題，並取得工作進度的透明度。
- 技術擁有者可以更輕鬆地檢閱內容建立者的提取要求，如果變更已適當地批次處理，並具有明確的認可訊息。
當您暫存並認可 Power BI 內容的變更時，請考慮下列因素。
- 無論您是從本機存放庫還是從 Fabric 工作區暫存及認可變更。
- 當您將多個模型或報表儲存在單一存放庫時，請將 .pbip 檔案放在最上層資料夾中。 這可讓您更輕鬆地識別您所做的變更並加以分組。
- 使用 gitignore 檔案或 .gitattributes 檔案忽略無害或無用的中繼資料變更。 這可確保您認可的所有變更都有意義。
提示
如需如何將工作暫存並認可至 Git 存放庫的特定指引和建議，請參閱使用認可儲存您的工作。
建立提取要求以合併變更
若要合併變更，內容建立者會開啟「提取要求」。 提取要求是指提交變更給同儕檢閱，以將所進行的工作合併成單一解決方案。 合併可能會導致衝突，必須先加以解決才能合併分支。 提取要求檢閱對於確保建立者遵守開發、品質和合規性方面的組織標準與做法來說很重要。
當您使用提取要求來合併對 Power BI 內容進行的變更時，請考慮下列因素。
- 您將使用哪些標準和做法來執行您的檢閱 (若有)。 例如，您可以針對語意模型使用最佳做法分析器中的規則。
- 您將如何檢閱對報表中繼資料進行的變更，這在不使用第三方工具的情況下，不容易閱讀和了解。
- 您將如何解決及解析合併衝突。
檢查清單 - 規劃儲存盤案的位置時，關鍵決策和動作包括：
- 選擇您的開發工具：確定開發內容的方法與您將與其他內容建立者共同作業和使用版本控制的方式一致。
- 在模型和報表的 .pbip 與 .pbix 格式之間進行選擇：一般而言，.pbip 格式對原始檔控制更有幫助，但自助使用者會發現 .pbix 檔案更容易使用。
- 個別語意模型和報表開發：當您個別管理不同項目類型的變更時，版本控制最有效。 將模型和報表開發區隔視為良好做法。
- 決定您需要的工作區數目：使用個別的環境對於內容生命週期管理的成功至關重要。 請確定您已釐清您需要多少工作區，並進行適當的工作區層級規劃。
- 決定您將實作版本控制的方式：使用 SharePoint 或商務用 OneDrive，或使用 Azure DevOps 協助原始檔控制，決定使用更簡單的方法。
- 設定遠端存放庫：在 OneDrive 資料夾或 Git 存放庫中建立結構化空間，您將在其中儲存內容以追蹤及管理變更。
- 如果您使用原始檔控制，請設定 .gitignore 和 .gitattributes 檔案：請確定您已設定存放庫，以便僅追蹤有意義的變更。
- 如果您使用原始檔控制，請定義分支及合併策略：請確定您已定義清楚的程序，了解如何設定及使用原始檔控制，以獲得最佳支援開發。 避免使您的程序過度複雜化。 相反地，請嘗試補充開發小組中目前的工作方式。
相關內容
在本系列的下一篇文章中，了解如何在管理內容生命週期時驗證內容。