Power BI 使用案例：企業內容發佈
注意
本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介，請參閱 Power BI 實作規劃。
當內容建立者共同作業以傳遞對組織而言很重要的分析解決方案時，其必須確保內容能夠及時且可靠地傳遞給取用者。 技術小組會使用稱為 DevOps 的程序來解決這項挑戰。 DevOps 可讓小組藉由採用可改善和加速傳遞的做法來為程序進行自動化和縮放。
注意
解決相同挑戰的資料小組也可以練習 DataOps。 DataOps 建置在 DevOps 原則之上，但 DataOps 另外包含資料管理特有的做法，例如資料品質保證和治理。 本文提及的是 DevOps，但請注意，這些基本原則也適用於 DataOps。
採用 DevOps 做法來發佈 Power BI 內容時，內容建立者和取用者可受益於數個優點。 以下幾點是此程序運作方式的高階概觀。
- 開發內容並將工作認可到遠端存放庫：內容建立者在自己的機器上開發其解決方案。 在開發期間，其定期認可工作並將工作儲存到「遠端存放庫」。 遠端存放庫包含最新版本的解決方案，且可供整個開發小組存取。
- 使用版本控制共同作業和管理內容變更：其他內容建立者可以藉由建立「分支」來對解決方案進行修訂。 分支是遠端存放庫的複本。 當這些修訂準備就緒並獲得核准時，分支就會與解決方案的最新版本合併。 解決方案的所有修訂都會受到追蹤。 此程序稱為「版本控制」(或「原始檔控制」)。
- 使用管線進行內容的部署和升階：在自助式內容發佈使用案例中，我們會使用 Power BI 部署管線將內容升階 (或「部署」) 到開發工作區、測試工作區和生產工作區。 Power BI 部署管線能以手動方式使用使用者介面將內容升階至 Power BI Premium 工作區，也能以程序設計方式使用 REST API 來進行升階。 相反地，企業內容發佈 (本使用案例的重點) 則會使用 Azure Pipelines 將內容升階。 Azure Pipelines 是一項 Azure DevOps 服務，其會使用一系列自訂的程式設計步驟，來自動測試、管理和部署內容。 在企業內容發佈使用案例中，這些管線也可以稱為「持續整合和持續部署」(簡稱 CI/CD) 管線。 這些管線會經常自動整合變更並簡化內容發佈。
重要
本文有時會提及 Power BI Premium 或其容量訂用帳戶 (P SKU)。 請注意，Microsoft 目前正在整合購買選項，並按容量 SKU 淘汰 Power BI Premium。 新客戶和現有客戶應考慮改為購買 Fabric 容量訂用帳戶 (F SKU)。
如需詳細資訊，請參閱 Power BI Premium 授權的重要更新 (英文) 和 Power BI Premium 常見問題集 (部分機器翻譯)。
DevOps 能以成熟、有系統的方法支援內容的管理和發佈。 其可讓內容建立者在解決方案上共同作業，並確保內容能夠快速且可靠地傳遞給取用者。 當您遵守 DevOps 做法時，便能從適用於內容建立者和內容取用者的簡化工作流程、較少的錯誤和有所改善的體驗獲得好處。
您可以使用 Azure DevOps 來設定及管理 Power BI 解決方案的 DevOps 做法。 在企業案例中，您可以使用 Azure DevOps 和 Power BI REST API，以三種不同的方式來自動發佈內容。
- Power BI REST API 搭配 Power BI 部署管線：您可以將內容匯入到開發工作區，然後使用部署管線將內容部署到測試工作區和生產工作區。 您仍會從 Azure DevOps 控制部署，並使用 Power BI REST API 來管理部署管線，而不是個別的內容項目。 此外，您還會使用 XMLA 端點，透過 Azure DevOps 來部署資料模型中繼資料，而不是 Power BI Desktop 檔案 (.pbix)。 此中繼資料可讓您使用版本控制來追蹤物件層級的變更。 雖然這種方法強固性更高且更容易維護，但需要 Premium 授權並適度編寫指令碼，才能使用 Power BI REST API 來設定內容的匯入和部署。 當您想要使用部署管線來簡化內容的生命週期管理，而且您有 Premium 授權時，請使用此方法。 XMLA 端點和 Power BI 部署管線是 Premium 功能。
- Power BI REST API：您也可以使用 Azure DevOps 以及只靠 Power BI REST API，將內容匯入到開發工作區、測試工作區和生產工作區。 這種方法不需要 Premium 授權，但需要編寫大量指令碼並進行設定，因為部署是在 Power BI 之外進行管理。 當您想要集中從 Azure DevOps 部署 Power BI 內容，或當您沒有 Premium 授權時，請使用此方法。 如需前兩種方法的視覺比較，請參閱發行管線方法流程圖。
- Power BI 自動化工具搭配 Power BI 部署管線：您可以使用 Power BI 自動化工具 Azure DevOps 延伸模組來管理部署管線，而不是使用 Power BI REST API。 此方法是第一個選項的替代方案，其會使用 Power BI REST API 並搭配 Power BI 部署管線。 Power BI 自動化工具延伸模組是開放原始碼工具。 其可協助您從 Azure DevOps 管理和發佈內容，而不需要撰寫 PowerShell 指令碼。 當您想要以最少的指令碼編寫工作從 Azure DevOps 管理部署管線，而且您有 Premium 容量時，請使用此方法。
本文著重於第一個選項，也就是使用 Power BI REST API 並搭配 Power BI 部署管線。 文中會說明如何使用 Azure DevOps 來設定 DevOps 做法。 文中也會說明如何將 Azure Repos 用於您的遠端存放庫，以及如何使用 Azure Pipelines 來自動測試、整合和傳遞內容。 並非只能透過 Azure DevOps 來設定企業內容的發佈，但因其能與 Power BI 輕鬆整合，因此是不錯的選擇。
注意
此使用案例是其中一個內容管理和部署案例。 為求簡潔，本文並未涵蓋內容共同作業和傳遞案例主題所說到的某些方面。 如需完整的涵蓋內容，請先閱讀這些文章。
提示
Microsoft Fabric 藉由使用 Fabric Git 整合來提供其他的企業內容發佈選項。 Git 整合可讓您將 Fabric 工作區連結至 Azure Repos 遠端存放庫中的分支。 儲存至該分支的內容會自動同步至工作區，看起來就像該內容是發佈至工作區一樣。 反過來，內容建立者也可以將變更從 Fabric 工作區認可並推送至遠端存放庫。
Git 整合可以簡化共同作業和內容發佈，但需要您對如何使用 Fabric 工作區以及您的分支策略是什麼做更多的規劃。 如需如何設定和使用 Fabric Git 整合的詳細資訊，請參閱開始使用 Git 整合或 教學課程：端對端生命週期管理。
案例圖表
下圖描述支援企業內容發佈之最常見使用者動作和 Power BI 元件的高階概觀。 重點放在使用 Azure DevOps 於 Power BI 服務中，以程式設計方式大規模地在開發工作區、測試工作區和生產工作區中管理及發佈內容。
提示
如果您想要將此案例圖表內嵌在簡報、文件或部落格文章中，或將其列印成牆面海報，建議您下載案例圖表。 此圖表是可縮放向量圖形 (SVG) 影像，因此您可以將其擴大或縮小，而不會降低品質。
此案例圖表描述下列使用者動作、程序和功能。
| 項目 | 說明 |
|---|---|
 |
內容建立者使用 Power BI Desktop 或 Tabular Editor 來開發資料模型，並使用 Power BI Desktop 來開發報表。 內容建立者在開發期間將其工作儲存至本機存放庫。 |
 |
內容建立者可以複製遠端存放庫，以取得該內容的本機複本。 |
 |
某些資料來源可能需要內部部署的資料閘道或 VNet 閘道以便重新整理資料，例如位於私人組織網路內的資料來源。 |
 |
內容建立者在開發期間使用 Visual Studio Code 等 Git 用戶端，定期認可變更並推送至遠端存放庫。 在此圖表中，遠端存放庫是 Azure Repos。 |
 |
其他內容建立者使用 Azure Repos，透過版本控制來追蹤變更。 其藉由將變更認可至不同分支來進行共同作業。 |
 |
遠端存放庫中的內容變更觸發 Azure Pipelines。 驗證管線是第一個觸發的管線。 驗證管線會執行自動化測試，先驗證內容再進行發佈。 |
 |
通過驗證管線的內容觸發後續的建置管線。 建置管線準備內容以發佈至 Power BI 服務。 到此為止的程序通常稱為「持續整合」(CI)。 |
 |
系統使用發行管線來發佈和部署內容。 發行管線使用 Power BI REST API 或工作區 XMLA 端點，以程式設計方式將內容匯入到 Power BI 服務。 使用發行管線所進行的部署通常稱為「持續部署」(CD)。 |
 |
發行管理員使用 Azure Pipelines 發行核准，來控制測試工作區和生產工作區的部署。 在企業內容發佈中，發行管理員通常會規劃和協調內容在測試環境和生產環境的發行。 其會與內容建立者、專案關係人和使用者進行協調和通訊。 |
 |
發行管線將內容發佈至開發工作區，或將內容從開發工作區升階至測試工作區，或從測試工作區升階至生產工作區。 |
 |
在具有 Fabric 容量授權模式的工作區中工作的內容建立者可以使用 Git 整合。 透過 Git 整合，內容建立者可以在開發期間於私人工作區中工作。 內容建立者將遠端分支 (通常是特定的功能分支或 Bug 分支) 從 Azure Repos 同步至其私人工作區。 內容的變更會在 Azure Repos 中的遠端分支與工作區之間進行同步。 在此案例中，內容建立者不需要使用 Azure Pipelines 來發佈內容。 內容建立者在發佈內容後，也可以定期認可和推送來自工作區的變更。 準備好時，內容建立者可提出提取要求 (PR)，以將其變更合併至主要分支。 |
 |
使用 Git 整合時，開發工作區會與主要分支同步，以取得最新版本的內容。 這個內容會包含提取要求中，發行管理員所檢閱、核准和合併的所有變更。 |
 |
工作區會設定為 [Fabric 容量]、[Premium 容量]、[Premium Per User] 或 [內嵌] 授權模式，以允許使用 Power BI 部署管線和 XMLA 讀取/寫入端點。 |
 |
部署管線系統管理員使用三個階段來設定 Power BI 部署管線：開發、測試和生產。 每個階段都對應至 Power BI 服務中的不同工作區。 系統會針對部署管線設定部署設定和存取權。 |
 |
開發工作區包含最新版本的內容，包括所有已核准和已合併的變更。 獲得核准後，發行管線將內容從開發工作區部署至測試工作區。 |
 |
測試工作區內的檢閱者對內容執行測試和品質保證。 獲得核准後，發行管線將內容從測試工作區部署至生產工作區。 使用 Git 與部署管線的整合時，測試工作區不會與任何分支同步。 |
 |
部署管線完成部署之後，內容建立者手動執行部署後活動。 活動可能包括設定已排程的資料重新整理，或更新生產工作區的 Power BI 應用程式。 使用 Git 與部署管線的整合時，生產工作區不會與任何分支同步。 |
 |
內容檢視者使用生產工作區或 Power BI 應用程式來存取內容。 |
重點
以下是關於企業內容發佈案例所要強調的一些重點。
版本控制
在內容生命週期期間追蹤變更非常重要，因為這能確保內容會穩定且一致地傳遞給取用者。 在此使用案例中，內容建立者和擁有者會使用「版本控制」來管理遠端存放庫中的內容變更。 版本控制是在中央存放庫中管理檔案或程式碼變更的做法。 這種做法能提升共同作業體驗並有效管理版本歷程記錄。 版本控制能為內容建立者帶來好處，包括能夠復原或合併變更。
內容建立者通常會在 Tabular Editor 中開發資料模型，以支援更好的版本控制。 不同於您在 Power BI Desktop 中開發的資料模型，在 Tabular Editor 中開發的資料模型會以人類可讀的中繼資料格式加以儲存。 此格式可實現資料模型物件層級的版本控制。 在相同的資料模型上與多個人共同作業時，請使用物件層級的版本控制。 如需詳細資訊，請參閱進階資料模型管理使用案例。 您無法查看您在報表定義或資料模型等 Power BI Desktop 檔案 (.pbix) 中所做的變更。 舉例來說，您無法追蹤報表頁面的變更，例如所使用的視覺效果、其位置，以及其欄位對應或格式設定。
內容建立者會將資料模型中繼資料檔案和 .pbix 檔案儲存在中央遠端存放庫中，例如 Azure Repos。 這些檔案由技術擁有者策展。 當內容建立者開發解決方案時，技術擁有者負責管理解決方案並檢閱變更，以及將其合併成單一解決方案。 Azure Repos 提供了用於追蹤和管理變更的複雜選項。 此方法不同於自助式內容發佈使用案例中所述的方法，在後者，建立者會搭配版本追蹤使用 OneDrive 儲存體。 維護精心策展且有記載的存放庫非常重要，因為其為所有內容和共同作業的基礎。
以下是一些可協助您設定版本控制遠端存放庫的重要考量。
- 範圍：明確定義存放庫的範圍。 理想情況下，存放庫的範圍會與您用來將內容傳遞給取用者之下游工作區和應用程式的範圍相同。
- 存取：在設定存放庫存取權時，所使用的權限模型應與為部署管線權限和工作區角色所設定的權限模型類似。 內容建立者需要存放庫存取權。
- 文件：在存放庫中新增文字檔，以記載其用途、擁有權、存取權和已定義的程序。 例如，文件可以描述應該如何暫存和認可變更。
- 工具：為了認可變更並將變更推送至遠端存放庫，內容建立者需要 Visual Studio 或 Visual Studio Code 等 Git 用戶端。 Git 是一種分散式版本控制系統，可追蹤檔案中的變更。 若要了解 Git 的基本概念，請參閱什麼是 Git？。
注意
如果您打算認可 Power BI Desktop 檔案 (.pbix)，請考慮使用 Git 大型檔案儲存體 (LFS)。 Git LFS 提供了進階選項供您管理無法看見變更的檔案 (undiffable 檔案)，例如 .pbix 檔案。 舉例來說，您可以使用檔案鎖定來防止在開發期間同時變更 Power BI 報表。 不過，Git LFS 有自己的用戶端和設定。
使用 Azure DevOps 進行共同作業
隨著解決方案的範圍和複雜度增加，可能必須由多名內容建立者和擁有者以共同作業的方式一起處理解決方案。 內容建立者和擁有者會使用 Azure DevOps，在集中、有組織的中樞內進行通訊和共同作業。
為了在 Azure DevOps 中共同作業和通訊，您會使用支援服務。
- Azure Boards：內容擁有者會使用面板來追蹤「工作項目」。 工作項目會各自指派給小組上的某一位開發人員，並且會描述解決方案中的問題、Bug 或功能，以及對應的專案關係人。
- Azure Wiki：內容建立者會與其小組共用資訊，以了解並參與解決方案。
- Azure Repos：內容建立者會追蹤遠端存放庫中的變更，並將其合併成單一解決方案。
- Azure Pipelines：管線擁有者會設定程式設計邏輯，以便自動或隨選部署解決方案。
共同作業流程圖
下圖描述 Azure DevOps 如何在企業內容發佈使用案例中實現共同作業的其中一個範例的高階概觀。 此圖的重點在於使用 Azure DevOps 來建立結構化和有記載的內容發佈程序。
此圖會描述下列使用者動作、程序和功能。
| 項目 | 說明 |
|---|---|
|
內容建立者藉由複製包含最新版內容的主要分支來建立新的短期分支。 新分支通常稱為「功能」分支，因為其會用來開發特定功能或修正特定問題。 |
|
內容建立者在開發期間將其變更認可至本機存放庫。 |
|
內容建立者將其變更連結至可在 Azure Boards 中管理的工作項目。 工作項目會描述範圍在其分支內的特定開發、改進或錯誤修正。 |
|
內容建立者定期認可其變更。 準備好時，內容建立者會將其分支發佈至遠端存放庫。 |
|
為了測試其變更，內容建立者將其解決方案部署到針對其開發所隔離的工作區 (此圖未顯示)。 內容建立者也可以使用 Fabric Git 整合，將功能分支同步至工作區。 |
|
內容建立者和內容擁有者在 Azure Wiki 中記載解決方案及其程序，以供整個開發小組檢視。 |
|
準備好時，內容建立者會開啟提取要求，以將功能分支合併至主要分支。 |
|
技術擁有者負責檢閱提取要求並合併變更。 當其核准提取要求時，便會將功能分支合併至主要分支。 |
|
合併成功時，便會觸發使用 Azure Pipeline 將解決方案部署至開發工作區的作業 (此圖未顯示)。 使用 Fabric Git 整合時，主要分支會同步至開發工作區。 |
|
發行管理員執行解決方案的最終檢閱和核准。 此發行核准可防止解決方案在準備好之前就發佈。 在企業內容發佈中，發行管理員通常會規劃和協調內容在測試工作區和生產工作區的發行。 其會與內容建立者、專案關係人和使用者進行協調和通訊。 |
|
當發行管理員核准發行時，Azure Pipelines 會自動準備解決方案以供部署。 或者，Azure Pipeline 也可以觸發部署管線，以在工作區之間進行內容升階。 |
|
使用者在測試工作區中測試及驗證內容。 使用 Git 與 Azure Pipelines 的整合來進行部署時，測試工作區不會與任何分支同步。 |
|
在使用者接受和驗證變更之後，發行管理員會執行解決方案的最終檢閱和核准，以將其部署至生產工作區。 |
|
使用者檢視發佈至生產工作區的內容。 使用 Git 與 Azure Pipelines 的整合來進行部署時，生產工作區不會與任何分支同步。 |
為了詳細說明，內容建立者會使用「分支策略」來達成共同作業。 分支策略是內容建立者用來建立、使用及合併分支，以有效進行和管理內容變更的方式。 個別內容建立者會以隔離的方式在其本機存放庫中工作。 準備好時，其便會將變更合併成遠端存放庫中的單一解決方案。 內容建立者應藉由將分支連結至特定開發、改進或錯誤修正的工作項目，以將其工作範圍限定在分支上。 每個內容建立者都會為其工作範圍建立自己的遠端存放庫分支。 在其本機解決方案上完成的工作會認可並推送至遠端存放庫中的某個分支版本，並附上「認可訊息」。 認可訊息會描述該認可中所進行的變更。
若要合併變更，內容建立者會開啟「提取要求」。 提取要求是指提交變更給同儕檢閱，以將所進行的工作合併成單一解決方案。 合併可能會導致衝突，必須先加以解決才能合併分支。 提取要求檢閱對於確保建立者遵守開發、品質和合規性方面的組織標準與做法來說很重要。
共同作業建議
建議您針對內容建立者的共同作業方式定義結構化的程序。 請務必要確定：
- 如何設定工作範圍，以及如何建立、命名及使用分支。
- 作者如何為變更分組，以及如何使用認可訊息加以描述。
- 誰負責檢閱和核准提取要求。
- 如何解決合併衝突。
- 在不同分支中所做的變更要如何合併成單一分支。
- 在部署內容前，如何測試內容及由誰執行測試。
- 將變更部署至開發工作區、測試工作區和生產工作區的方式和時機。
- 應該復原已部署的變更或解決方案版本的方式和時機。
重要
DevOps 所帶來的價值會與定義其用途之程序的遵守程式成正比。
成功的共同作業取決於定義完善的程序。 請務必清楚描述並記載端對端開發工作流程。 請確定所選取的策略和程序有與小組的現有做法相呼應，如果沒有，您會如何管理變更。 此外，也請確定程序清楚明瞭，並有傳達給所有小組成員和專案關係人。 確定不熟悉程序的小組成員和專案關係人會接受訓練，從而了解如何採用這些程序，並理解成功採用 DevOps 的價值。
Power BI REST API
您可以開發程式設計邏輯，以使用 Power BI REST API 從 Azure DevOps 匯入和部署內容。 您可以使用匯入作業將 Power BI 檔案 (.pbix) 匯入至工作區。 您可以使用管線作業，透過 Power BI 部署管線將某些內容或所有內容部署至測試工作區或生產工作區。 程序設計邏輯會定義在 Azure Pipelines 中。
建議您使用服務主體在管線中呼叫 Power BI REST API。 服務主體適用於無人參與的自動化活動，且不依賴使用者認證。 不過，某些項目和活動不受 Power BI REST API 支援或於使用服務主體時不受支援，例如資料流程。
當您使用服務主體時，請務必仔細管理權限。 您的目標應該是遵循最低權限原則。 您應該為服務主體設定足夠的權限就好，而不過度佈建權限。 使用 Azure Key Vault 或其他可安全地儲存服務主體秘密和認證的服務。
警告
如果您有儲存為人類可讀中繼資料格式的資料模型，則無法使用 Power BI REST API 來發佈。 相反地，您必須使用 XMLA 端點來發佈。 您可以使用 Tabular Editor 命令列介面 (CLI) 等第三方工具來發佈中繼資料檔案。 您也可以使用自己的自訂 .NET 開發，以程式設計方式發佈中繼資料檔案。 開發自訂解決方案會更費力，因為您必須使用分析管理物件 (AMO) 用戶端程式庫的 Microsoft 表格式物件模型 (TOM) 延伸模組。
Azure Pipelines
Azure Pipelines 會以程式設計方式自動測試、管理和部署內容。 執行管線時，管線中的步驟會自動執行。 管線擁有者可以自訂其觸發程序、步驟和功能，以符合部署需求。 因此，管線的數目和類型會根據解決方案需求而有所不同。 例如，Azure Pipeline 可以在部署之前先執行自動化測試或修改資料模型參數。
您可以設定三種類型的 Azure Pipelines 來測試、管理及部署 Power BI 解決方案：
- 驗證管線。
- 建置管線。
- 發行管線。
注意
發佈解決方案中不需要同時具備這三種管線。 視您的工作流程和需求而定，您可以設定本文所述之管線的一或多個變體，以將內容發佈自動化。 自訂管線的能力是 Azure Pipelines 優於內建 Power BI 部署管線的地方。 例如，您不需要有驗證管線；您可以只使用建置管線和發行管線。
驗證管線
驗證管線會在資料模型發佈至開發工作區之前，先對資料模型執行基本的品質檢查。 一般而言，遠端存放庫分支中的變更會觸發管線，以使用自動化測試來驗證這些變更。
自動化測試的範例包括使用最佳做法分析器 (BPA)，或針對已發佈的語意模型執行 DAX 查詢，藉此來掃描資料模型以了解是否有違反最佳做法規則的地方。 然後，這些測試的結果會儲存在遠端存放庫中，以供記載和稽核之用。 驗證失敗的資料模型不應發佈。 相反地，管線應該通知內容建立者有問題發生。
建置管線
建置管線會準備要發佈至 Power BI 服務的資料模型。 這些管線會將序列化的模型中繼資料合併成單一檔案以於稍後供發行管線發佈 (如發行管線圖所述)。 建置管線也可以對中繼資料進行其他變更，例如修改參數值。 建置管線會產生部署成品，其中包含可供發佈至 Power BI 服務的資料模型中繼資料 (適用於資料模型) 和 Power BI Desktop 檔案 (.pbix)。
發行管線
發行管線會發佈或部署內容。 視目標環境而定，發佈解決方案通常會包含數個發行管線。
- 開發發行管線：第一個管線會自動觸發。 其會在建置管線和驗證管線成功之後，將內容發佈至開發工作區。
- 測試和生產發行管線：這些管線不會自動觸發。 相反地，其會視需要觸發，或在核准時才觸發。 測試和生產發行管線會在「發行核准」後，分別將內容部署到測試工作區或生產工作區。 發行核准可確保內容在準備好之前，不會自動部署到測試階段或生產階段。 這些核准會由發行管理員提供，其負責規劃和協調測試環境和生產環境的內容發行。
有兩種不同的方法可透過測試管線和發行管線來發佈內容。 其會使用 Power BI 部署管線將內容升階，或從 Azure DevOps 將內容發佈至 Power BI 服務。
下圖描述第一種方法。 在此方法中，發行管線會使用 Power BI 部署管線來協調將內容部署至測試工作區和生產工作區。 內容會沿著 Power BI 中的開發工作區、測試工作區和生產工作區來升階。 雖然這種方法強固性更高且更容易維護，但需要 Premium 授權。
此圖會描述第一種方法的下列使用者動作、程序和功能。
| 項目 | 說明 |
|---|---|
|
在第一種方法中，發行管線會使用 XMLA 端點和 Power BI REST API 搭配 Power BI 部署管線來發佈內容。 內容會先發佈，然後沿著開發工作區、測試工作區和生產工作區來升階。 Power BI 部署管線和 XMLA 讀取/寫入端點是 Premium 功能。 |
|
成功合併分支或完成上游管線便會觸發建置管線。 建置管線接著會準備內容以供發佈，並觸發開發發行管線。 |
|
開發發行管線會使用 XMLA 端點 (適用於資料模型中繼資料) 或 Power BI REST API (適用於 Power BI Desktop 檔案，可包含資料模型和報表)，將內容發佈至開發工作區。 開發管線會使用 Tabular Editor 命令列介面 (CLI)，透過 XMLA 端點來部署資料模型中繼資料。 |
|
發行核准或隨選觸發程序會啟動測試發行管線。 |
|
測試發行管線會使用執行 Power BI 部署管線的 Power BI REST API 部署作業來部署內容。 |
|
Power BI 部署管線會將內容從開發工作區升階至測試工作區。 部署之後，發行管線會使用 Power BI REST API 來執行部署後活動 (此圖未顯示)。 |
|
發行核准或隨選觸發程序會啟動生產發行管線。 |
|
生產發行管線會使用執行 Power BI 部署管線的 Power BI REST API 部署作業來部署內容。 |
|
Power BI 部署管線會將內容從測試工作區升階至生產工作區。 部署之後，發行管線會使用 Power BI REST API 來執行部署後活動 (此圖未顯示)。 |
下圖描述第二種方法。 此方法不會使用部署管線。 相反地，其會使用發行管線將內容從 Azure DevOps 發佈至測試工作區和生產工作區。 值得注意的是，當您只使用 Power BI REST API 來發佈 Power BI Desktop 檔案時，第二種方法不需要 Premium 授權。 其確實涉及更多的設定工作和複雜度，因為您必須在 Power BI 之外管理部署。 已針對 Power BI 之外的資料解決方案使用 DevOps 的開發小組可能會更熟悉此方法。 使用此方法的開發小組可以合併 Azure DevOps 中的資料解決方案部署。
此圖會描述第二種方法中的下列使用者動作、程序和功能。
| 項目 | 說明 |
|---|---|
|
在第二種方法中，發行管線會只使用 XMLA 端點和 Power BI REST API 來發佈內容。 內容會發佈至開發工作區、測試工作區和生產工作區。 |
|
成功合併分支或完成上游管線便會觸發建置管線。 建置管線接著會準備內容以供發佈，並觸發開發發行管線。 |
|
開發發行管線會使用 XMLA 端點 (適用於資料模型中繼資料) 或 Power BI REST API (適用於 Power BI Desktop 檔案，可包含資料模型和報表)，將內容發佈至開發工作區。 開發管線會使用 Tabular Editor 命令列介面 (CLI)，透過 XMLA 端點來部署資料模型中繼資料。 |
|
發行核准或隨選觸發程序會啟動測試發行管線。 |
|
開發發行管線會使用 XMLA 端點 (適用於資料模型中繼資料) 或 Power BI REST API (適用於 Power BI Desktop 檔案，可包含資料模型和報表)，將內容發佈至測試工作區。 開發管線會使用 Tabular Editor 命令列介面 (CLI)，透過 XMLA 端點來部署資料模型中繼資料。 部署之後，發行管線會使用 Power BI REST API 來執行部署後活動 (此圖未顯示)。 |
|
發行核准或隨選觸發程序會啟動生產發行管線。 |
|
開發發行管線會使用 XMLA 端點 (適用於資料模型中繼資料) 或 Power BI REST API (適用於 Power BI Desktop 檔案，可包含資料模型和報表)，將內容發佈至生產工作區。 開發管線會使用 Tabular Editor 命令列介面 (CLI)，透過 XMLA 端點來部署資料模型中繼資料。 部署之後，發行管線會使用 Power BI REST API 來執行部署後活動 (此圖未顯示)。 |
發行管線應該管理部署後活動。 這些活動可能包括設定語意模型認證，或更新用於測試工作區和生產工作區的 Power BI 應用程式。 建議您設定通知，以讓相關人員知道有部署活動。
提示
使用版本控制存放庫可讓內容建立者建立復原程序。 復原程序可以藉由還原舊版來反轉最後一個部署。 請考慮另外建立一組 Azure Pipelines，以供您觸發來復原生產變更。 請仔細思考要起始復原所需的程序和核准。 請確定這些程序都有記載下來。
Power BI 部署管線
Power BI 部署管線包含三個階段：開發、測試和生產。 您只能為部署管線中的每個階段各指派一個 Power BI 工作區。 部署發生時，部署管線會將 Power BI 項目從某個工作區升階到另一個工作區。
Azure Pipelines 發行管線會使用 Power BI REST API，使用 Power BI 部署管線來部署內容。 執行部署的使用者需要工作區和部署管線的存取權。 建議您規劃部署管線的存取權，讓管線使用者可以檢視部署歷程記錄並比較內容。
提示
當您將資料工作區與報告工作區分開時，請考慮使用 Azure Pipelines 來協調透過多個 Power BI 部署管線所進行的內容發佈。 語意模型會先進行部署，然後再進行重新整理。 最後，會部署報表。 這種方法可協助您簡化部署。
Premium 授權
Power BI 部署管線和 XMLA 讀取/寫入端點是 Premium 功能。 Power BI Premium 容量和 Power BI Premium Per User (PPU) 有提供這些功能。
在管理開發工作區和測試工作區的企業內容發佈時，PPU 是符合成本效益的方式，這種方式通常會有很少的使用者。 這種方法具有將開發和測試工作負載與生產工作負載分開的額外好處。
注意
您仍然可以在沒有 Premium 授權的情況下設定企業內容發佈，如發行管線一節中的第二種方法所述。 在第二種方法中，您可以使用 Azure Pipelines 來管理將 Power BI Desktop 檔案部署至開發工作區、測試工作區和生產工作區的作業。 不過，您無法使用 XMLA 端點來部署模型中繼資料，因為您無法在使用 Power BI REST API 的情況下發佈中繼資料格式的語意模型。 此外，您也無法在沒有 Premium 授權的情況下，使用部署管線將內容升階至各個環境。
閘道安裝
在存取位於私人組織網路或虛擬網路內的資料來源時，通常需要資料閘道。 資料閘道的兩個用途是重新整理匯入的資料，以及檢視會查詢即時連線或 DirectQuery 語意模型的報表 (案例圖表中未描述)。
在使用多個環境時，常會設定針對不同來源系統的開發連線、測試連線和生產連線。 在此情況下，請使用資料來源規則和參數規則來管理會隨環境而不同的值。 您可以藉由 Power BI REST API 的閘道作業，使用 Azure Pipelines 來管理閘道。
注意
強烈建議您使用「標準模式」的集中式資料閘道，而不要使用「個人模式」的閘道。 在標準模式中，除了已排程的資料重新整理作業外，資料閘道還支援即時連線和 DirectQuery 作業。
系統監督權
活動記錄會記錄 Power BI 服務中發生的事件。 Power BI 系統管理員可以使用活動記錄來稽核部署活動。
您可以使用 Power BI 中繼資料掃描 API 來建立租用戶清查。 API 結果有助於驗證每個工作區中已部署的項目、檢查譜系，以及驗證安全性設定。
Azure DevOps 內也有稽核記錄，其位於 Power BI 服務之外。 Azure DevOps 系統管理員可以使用稽核記錄來檢閱遠端存放庫和管線中的活動。
相關內容
如需可協助您進行 Power BI 實作決策的其他實用案例，請參閱 Power BI 使用案例一文。