共用方式為

Power BI 實作規劃：部署內容

  • 發行項

注意

本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介，請參閱 Power BI 實作規劃。

本文可協助您在管理內容生命週期時部署內容。 本文的主要目標讀者為：

  • Fabric 管理員：負責監督組織中 Fabric 的管理員。 Fabric 管理員可能需要與其他管理員共同作業，例如負責監督 Microsoft 365 或 Azure DevOps 的人員。
  • 卓越中心 (COE) 和 BI 小組：這類小組負責監督組織中的 Power BI。 這些小組包含決定如何管理 Power BI 內容生命週期的決策者。 這些小組也包含發佈管理員 (負責處理內容發佈生命週期) 及工程視 (負責建立和管理有效使用和支援生命週期管理所需的元件)。
  • 內容建立者和內容擁有者：建立要發佈至 Fabric 入口網站以與其他人員共用內容的使用者。 這些人員負責管理所建立 Power BI 內容的生命週期。

生命週期管理包含您用於處理內容的程序和做法，涵蓋內容的建立到最終淘汰。 在生命週期管理的第三個階段中，您會驗證內容變更，這牽涉到內容建立者和使用者所執行的驗證。 在第四個階段中，您會部署內容以供取用者使用。

若要與取用者共用 Power BI 內容，您應該先將內容發佈 (或部署) 至 Fabric 工作區。 部署內容也牽涉到在環境之間移動該內容，例如從開發工作區部署至測試工作區，或從測試工作區移至生產工作區。

下列影像描述 Power BI 內容的生命週期，其中醒目提示第四階段 (部署內容)。

圖表顯示 Power BI 內容生命週期。已醒目提示第 4 階段，這是內容部署階段。

注意

如需內容生命週期管理的概觀，請參閱本系列的第一篇文章。

本文的重點在於在整個生命週期中部署內容的重要考量和決策。 如需如何部署內容的詳細指導，請參閱：

您可以在內容生命週期期間，在兩個主要點部署內容：

  • 當您將內容發佈至開發工作區時。 此時，您會發佈內容來驗證變更。
  • 當您在兩個工作區之間升階內容時 (例如將內容從開發工作區升階至測試工作區)。 此時，您會在準備好進入下一個階段時部署內容 (例如，當新內容準備好進行測試時)。

下列各節概述您可以採取以發佈或升階內容的方法。

決定您發佈內容的方式

當您在本機電腦上開發內容時，必須在 Fabric 入口網站中將該內容發佈至開發工作區。 當您想要對所做的變更執行驗證時，通常會發佈此內容。

注意

在本文中，我們會將內容發佈稱為開發工作區的初始部署。 不過，原則上發佈內容與部署內容相同。

在 Fabric 入口網站中建立的內容 (例如資料流程、儀表板和計分卡) 會直接在開發工作區中建立，且不需要發佈。

下列各節說明您可以採取以發佈內容的不同方法。

使用 Power BI Desktop 發佈

Power BI Desktop 可讓使用者將語意模型和報表從其本機電腦發佈至 Fabric 入口網站中的工作區。 這種方法是發佈內容最簡單的方式；不過，它無法自動化。

圖表顯示方法 1，也就是從 Power BI Desktop 發佈。接下來會說明圖表中的項目。

請考慮在下列情況下使用此方法：

  • 內容建立者偏好手動控制發佈至 Fabric 入口網站的內容。
  • 內容建立者會使用 Power BI Desktop 來開發和管理內容。
  • 內容建立者不熟悉 Azure DevOps 或 Git。
  • 內容只包含語意模型或報表。

使用第三方工具發佈

第三方工具可讓內容建立者使用工作區 XMLA 讀取/寫入端點來發佈語意模型。 例如，內容建立者會使用表格式編輯器來開發和管理模型中繼資料，例如TMDL (表格式模型定義語言) 或 .bim 檔案。

圖表顯示方法 2，也就是從第三方工具發佈。接下來會說明圖表中的項目。

提示

如需如何使用第三方工具來部署語意模型的詳細資訊，請參閱進階資料模型管理使用案例。

如需如何啟用和使用 XMLA 讀取/寫入端點的詳細資訊，請參閱與 XMLA 端點的語意模型連線。

請考慮在下列情況下使用此方法：

  • 內容建立者偏好手動控制發佈至 Fabric 入口網站的內容。
  • 內容建立者會使用第三方工具來開發和管理內容。
  • 內容將會發佈至使用 Premium Per User (PPU)、Premium 容量或 Fabric 容量授權模式的工作區。
  • 內容建立者不熟悉 Azure DevOps 或 Git。
  • 內容只包含語意模型。

使用 OneDrive 重新整理發佈

OneDrive 可讓自助內容建立者使用 OneDrive 重新整理，自動將語意模型或報表發佈至 Fabric 入口網站中的工作區。 內容建立者可以將 Power BI Desktop (.pbix) 檔案儲存到 OneDrive 中的共用文件庫。 共用文件庫也可以是 SharePoint 或 Microsoft Teams 文件庫。

圖表顯示方法 3，也就是使用 OneDrive 重新整理發佈。接下來會說明圖表中的項目。

提示

如需如何使用公司用和學校用 OneDrive 搭配 Power BI 內容的詳細資訊，請參閱自助內容發佈使用案例。

如需如何設定 OneDrive 重新整理的詳細資訊，請參閱重新整理儲存在 OneDrive 或 SharePoint Online上的語意模型。

請考慮在下列情況下使用此方法：

  • 內容建立者想要將內容發佈至 Fabric 入口網站的作業自動化。
  • 內容建立者不熟悉 Azure DevOps 或 Git。
  • 內容建立者會使用 OneDrive 或 SharePoint 來執行內容的版本控制。
  • 內容建立者會將語意模型和報表儲存為 .pbix 檔案。
  • 內容只包含語意模型或報表。

使用 Fabric Git 整合發佈

Fabric Git 整合是 Fabric 容量專屬的功能，可讓內容建立者將分支從遠端 Git 存放庫同步至 Fabric 工作區。 您可以使用 Git 整合與 Azure DevOps 來同步 Azure Repos 的內容，或使用 Azure Pipelines 部署內容 (下一節說明)。

注意

Azure DevOps 是一套與 Power BI 和 Fabric 整合的服務，可協助您規劃和協調內容生命週期管理。 以這種方式使用 Azure DevOps 時，您通常會利用下列服務：

  • Azure Repos：可讓您建立及使用遠端 Git 存放庫，這是用來追蹤和管理內容變更的遠端儲存位置。
  • Azure Pipelines：可讓您建立和使用一組自動化工作來處理、測試及部署遠端存放庫的內容至工作區。
  • Azure Test Plans：可讓您設計測試來驗證解決方案，並將品質控制與 Azure Pipelines 一起自動化。
  • Azure Boards：可讓您使用面板來追蹤工作和計劃做為工作項目，以及連結或參照來自其他 Azure DevOps 服務的工作項目。
  • Azure Wiki：讓您與其小組共用資訊，以了解並參與內容。

總結來說，已認可並推送至遠端存放庫的內容，會透過此同步程序自動發佈至工作區。 這種方法的主要優點是，它可讓您將原始檔控制管理程序與內容發佈結合。 例如，它可讓您更輕鬆地復原變更或整個解決方案版本。

圖表顯示方法 4，也就是使用 Fabric Git 整合發佈。接下來會說明圖表中的項目。

提示

如需如何使用 Fabric Git 整合來部署 Power BI 內容的詳細資訊，請參閱企業內容發佈使用案例。

如需如何設定 Git 整合的詳細資訊，請參閱教學課程：Fabric 中的生命週期管理和 Power BI Desktop 專案：Git 整合。

請考慮在下列情況下使用此方法：

  • 內容建立者熟悉 Azure DevOps 和 Git。
  • 內容建立者會使用 Azure DevOps 進行共同作業和原始檔控制。
  • 內容建立者會將語意模型和報表儲存為 Power BI 專案 (.pbip) 檔案。
  • 內容將會發佈至 Fabric 容量上的工作區。
  • 內容是由 Git 整合功能支援的項目類型所組成。
  • 內容沒有敏感度標籤。

注意

使用 Git 整合來部署和管理內容的方式會高度相依於分支和合併策略，這會在您生命週期管理的第二階段中決定。

使用 Azure Pipelines 發佈

Azure Pipelines 會以程式設計方式自動測試、管理和部署內容。 執行管線時，管線中的步驟會自動執行。 相較於其他方法，Azure Pipelines 更複雜，且需要更多時間和工作來設定，但它在協調部署程序時最具有控制能力和彈性。

圖表顯示方法 5，也就是在 Azure DevOps 中使用 Azure Pipelines 發佈。接下來會說明圖表中的項目。

提示

您可以使用 Azure Pipelines 和 Power BI REST API 將內容部署到不在 Fabric 或 Premium 容量上的工作區。 不過，Fabric REST API 僅適用於 Fabric，而 XMLA 端點只能搭配 Fabric 或 Premium 容量使用。

如需如何使用 Azure Pipelines 部署 Power BI 內容的詳細資訊，請參閱企業內容發佈使用案例。

如需如何整合 Azure DevOps 與 Power BI 的詳細資訊，請參閱 Power BI Desktop 專案 Azure DevOps 整合和建置管線。

請考慮在下列情況下使用 Azure Pipelines 協調內容部署：

  • 內容建立者熟悉 Azure DevOps 和 Fabric REST API。
  • 內容建立者會使用 Azure DevOps 進行共同作業和原始檔控制。
  • 內容建立者未使用 Fabric Git 整合。

Azure Pipelines 和其他程式碼型工具可以使用下列一或多個 API 或端點，以程式設計方式部署內容：

  • Power BI REST API：您可以使用不同的 Power BI REST API 端點來部署內容。 Power BI REST API 僅支援 Power BI 項目類型。
    • 匯入：您可以使用 Power BI REST API 發佈支援的項目，將有效的來源檔案匯入工作區 (例如 .pbix 檔案)。
    • 部署：您可以部署支援的項目，並在處於部署管線中的階段時，將項目從某個工作區升階至另一個工作區。
  • Fabric REST API：您可以使用不同的 Fabric REST API 端點來部署內容。 Fabric REST API 同時支援 Power BI 和 Fabric 項目類型。
    • 建立：您可以使用 Fabric REST API 搭配有效的項目定義來建立支援的項目。
    • 從 Git 更新：您可以使用 Git 整合，透過已連線遠端存放庫的內容來更新工作區。
  • XMLA 讀取/寫入端點：您可以使用 XMLA 端點搭配有效的 model.bim 檔案來建立或改變語意模型。 XMLA 端點可讓您將變更部署至特定模型物件，而不是整個模型。 Azure Pipelines 可以使用第三方工具 (例如表格式編輯器命令列介面)，以使用 XMLA 端點來部署語意模型。

提示

當您使用 Fabric 或 Power BI REST API 時，必須先在 Azure 中建立應用程式註冊 (這裡說明 Power BI Embedded)。 這需要 Microsoft Entra ID 租用戶和組織使用者，且可能是設定適當權限的複雜程序。 不過，您可以在筆記本中執行 Fabric REST API，而不需建立應用程式註冊。 這可簡化解決方案中的 API 設定和使用，因此您在使用 API 之前，不需要管理認證或進行任何設定。

若要在不註冊應用程式的情況下使用 Fabric REST API，請使用 Fabric 筆記本中的語意連結搭配 sempy 的 FabricRestClientClass 來呼叫 API。

Azure Pipelines 與 Power BI 整合搭配自動化測試，可協助您實現持續整合與持續部署 (CI/CD)。

使用 Azure Pipelines 時，管線擁有者可以自訂觸發程序、步驟和功能，以符合部署需求。 因此，管線的數目和類型會根據解決方案需求而有所不同。

您可以設定三種類型的 Azure Pipelines 來測試、管理及部署 Power BI 解決方案。

  • 驗證管線
  • 建置管線
  • 發行管線

注意

發佈解決方案中不需要同時具備這三種類型的管線。 視您的工作流程和需求而定，您可以設定本文所述之管線的一或多個變體，以將內容發佈自動化。 自訂管線的能力是 Azure Pipelines 優於內建 Fabric 部署管線的地方。

驗證管線

驗證管線會在資料模型發佈至開發工作區之前，先對資料模型執行基本的品質檢查。 一般而言，遠端存放庫分支中的變更會觸發管線，以使用自動化測試來驗證這些變更。

自動化測試的範例包括使用最佳做法分析器 (BPA)，或針對已發佈的語意模型執行 DAX 查詢，藉此來掃描資料模型以了解是否有違反最佳做法規則的地方。 然後，這些測試的結果會儲存在遠端存放庫中，以供記載和稽核之用。 驗證失敗的資料模型不應發佈。 相反地，管線應該通知內容建立者有問題發生。

建置管線

建置管線會準備要發佈至 Power BI 服務的資料模型。 這些管線會將序列化的模型中繼資料合併成單一檔案以於稍後供發行管線發佈。 建置管線也可以對中繼資料進行變更，例如修改參數值。 建置管線會產生部署成品，其中包含可供發佈至 Power BI 服務的資料模型中繼資料 (適用於資料模型) 和 Power BI 專案 (.pbip) 檔案。

發行管線

發行管線會發佈或部署內容。 視目標環境而定，發佈解決方案通常會包含數個發行管線。

  • 開發發行管線：第一個管線會自動觸發。 其會在建置管線和驗證管線成功之後，將內容發佈至開發工作區。
  • 測試和生產發行管線：這些管線不會自動觸發。 相反地，其會視需要觸發，或在核准時才觸發。 測試和生產發行管線會在「發行核准」後，分別將內容部署到測試工作區或生產工作區。 發行核准可確保內容在準備好之前，不會自動部署到測試階段或生產階段。 這些核准會由發行管理員提供，其負責規劃和協調測試環境和生產環境的內容發行。

決定如何在工作區之間升階內容

當您針對開發、測試和生產環境使用不同的環境時，必須將內容部署至這三個環境。 根據您的特定工作流程和需求，您可以採取不同的工具和方法，在工作區之間升階內容。

下列各節說明在工作區之間升階內容時可採取的方法。

警告

避免將內容從本機電腦手動發佈至測試和生產工作區。 這可能會導致錯誤，或因為錯誤而發生中斷。 一般而言，您應該只發佈至開發工作區，或您使用的私人工作區。

使用 Fabric 部署管線進行部署

部署管線可讓您設定兩個以上的階段 (例如開發、測試或生產環境)，並在這些階段之間部署 Fabric 內容。 管線系統管理員會將單一 Power BI 工作區指派給部署管線中的每個階段。 使用部署管線的方式取決於您決定如何設定和使用工作區。

請考慮在下列情況下使用部署管線：

  • 內容會部署至使用 PPU、Premium 容量或 Fabric 容量授權模式的工作區。
  • 部署管線支援內容項目類型和案例。

在下列情況下，請考慮部署管線以外的另一種方法：

  • 您偏好從遠端存放庫部署內容，例如使用 Azure Pipelines。
  • 您想要使用 Git 整合來同步遠端存放庫不同分支的不同階段，而不是部署內容。

提示

如需如何使用部署管線在工作區之間升階內容的詳細資訊，請參閱自助內容發佈和企業內容發佈使用案例。

如需部署管線的詳細資訊，請參閱部署管線：了解部署程序。

使用部署管線最簡單的方式是將所有內容發佈至單一工作區，並將其升階至單一部署管線內的後續階段。 下圖描述使用部署管線部署內容的第一種方法。

圖表顯示方法 1，也就是使用部署管線進行內容部署。接下來會說明圖表中的項目。

總而言之，內容建立者通常會先將內容發佈至管線的初始階段。 然後，為了將內容升階至後續階段，管線系統管理員會觸發部署。 部署發生時，部署管線會將內容中繼資料從一個工作區部署到下一個工作區。

當您在不同的工作區中依項目類型分隔內容時，您將使用不同的部署管線來部署此內容。 您可以使用自動繫結，跨工作區與多個部署管線連結內容。 跨部署管線自動繫結可確保內容會保持連結至個別階段中的適當項目。 例如，開發階段中的報表仍會連結到其他部署管線開發階段中的模型。 不過，如果您的案例要求您以不同的模式跨工作區連結內容，您也可以避免自動繫結行為。

下圖描述使用多個部署管線部署內容的第二種方法。

圖表顯示方法 2，也就是使用多個管線進行內容部署。接下來會說明圖表中的項目。

總而言之，使用多個部署管線部署內容類似於使用單一管線。 主要差異在於，您可以使用自動繫結，選擇性地連結跨工作區和部署管線連線的內容。 否則，這與第一種方法相同。

部署管線是彈性且直接的工具，適合用於改善自助式和企業案例的內容生命週期管理。

執行部署的使用者需要工作區和部署管線的存取權。 建議您規劃部署管線的存取權，讓管線系統管理員可以檢視部署歷程記錄並比較內容。 與多個內容建立者共同作業時，請考慮將管線存取限制為最適合監督部署和發行程序的發行管理員或技術擁有者。

此外，請考慮使用部署規則為不同階段的項目設定不同的組態。 例如，您可能想要開發工作區中的語意模型從開發資料庫取得資料，而生產工作區中的語意模型會從生產資料庫取得資料。

提示

如果有多人可以存取您的部署管線，建議您定期檢閱部署歷程記錄。 這些檢閱可協助您識別未核准的部署或部署失敗。

如果您使用自動繫結來跨部署管線連結項目，請確定您也會檢閱項目譜系，以識別由將連結內容發佈至錯誤階段而造成的自動繫結中斷。

您可以使用 Power BI REST API，以手動或以程式設計方式來觸發部署。 在這兩種情況下，您應該定義一個明確且可靠的程序，說明何時將內容升階至每個階段，以及如何復原非預期的變更。

手動執行部署

您可以使用 Fabric 部署管線手動部署內容。 您可以選擇部署所有內容或選取項目。 當某些內容準備好移至下一個階段時，選擇性部署可能會很有幫助，但部分項目仍在進行開發或驗證。 此外，當內容變更存在於較晚階段，但不在先前的階段中時，您可以執行回溯部署。

警告

使用部署管線時，建議您以單一方向部署內容，例如從開發到測試到生產工作區。 一般而言，您應該避免在後續階段對內容進行變更，然後這些變更在開發或測試中經過適當的驗證。

當您進行手動部署時，您可以比較階段來識別 [變更檢閱] 視窗中的內容變更。 當您不使用 Git 遠端存放庫進行原始檔控制時，此方法特別有用。

使用 Power BI REST API 來執行部署

您可以使用 Power BI REST API，透過部署管線來部署內容。 使用 REST API 的優點是您可以將部署自動化，並將其與其他工具整合，例如 Azure DevOps 中的 Azure Pipelines。

使用 Azure Pipelines 部署

Azure Pipelines 可讓您協調所有階段之間的部署。 透過這種方法，您可以使用 Fabric REST API 來部署和管理內容，並使用不同的 Azure Pipelines，例如驗證和發行管線。

請考慮在下列情況下使用 Azure Pipelines：

  • 您想要從 Azure DevOps 內集中部署的協調流程。
  • 內容建立者會使用 Azure DevOps 來共同作業及進行原始檔控制。

在下列情況下，請考慮使用 Azure Pipelines 以外的另一種方法：

  • 內容建立者不熟悉 Azure DevOps 或程式碼型部署。
  • 內容包括沒有支援定義或來源檔案格式的項目類型，例如儀表板。

使用 Azure Pipelines 部署內容的方法有兩種不同的方法。 它們會協調部署管線，或將內容部署至沒有部署管線的工作區。

使用 Azure Pipelines 協調 Fabric 部署管線

在此方法中，發行管線會使用部署管線來協調將內容部署至測試工作區和生產工作區。 內容會沿著 Fabric 中的開發工作區、測試工作區和生產工作區來升階。

下圖說明如何從 Azure Pipelines 協調部署管線。

圖表顯示方法 3，也就是從 Azure Pipelines 協調內容部署。接下來會說明圖表中的項目。

總而言之，內容建立者會將內容發佈至部署管線第一個階段的工作區。 然後，發行管理員會核准部署，以觸發 Azure Pipeline。 此管線會使用 Power BI REST API 在階段之間升階內容，讓中繼資料部署至另一個工作區。 這種方法的優點之一是，您可以透過部署管線協調多個 Fabric 項目類型的部署，因為某些項目類型是在 Fabric 入口網站中開發，因此無法單獨由 Azure Pipelines 部署。

僅使用 Azure Pipelines 部署內容

您也可以使用 Azure Pipelines，從 Azure DevOps 將內容部署至工作區。 此方法不會使用部署管線。 相反地，它會使用發行管線，透過使用 Fabric 或 Power BI REST API 或 XMLA 讀取/寫入端點以部署來源檔案或中繼資料檔案。 這些檔案通常會儲存在 Azure Repos Git 存放庫中。

下圖說明您只使用 Azure Pipelines 部署內容的方式。

圖表顯示方法 4，也就是僅使用 Azure Pipelines 進行內容部署。接下來會說明圖表中的項目。

總而言之，內容建立者會認可內容變更，並將內容變更推送至 Azure Repos 中的遠端 Git 存放庫。 Azure Pipelines 會使用此內容進行部署。 發行管理員核准特定部署之後，Azure Pipeline 會使用 Power BI REST API (也就是 .pbix 檔案)、Fabric REST API (也就是項目定義) 或 XMLA 端點 (也就是 model.bim 檔案) 將內容部署至工作區。 每個工作區都有個別的 Azure Pipeline。

當您只使用 Power BI REST API 來發佈 Power BI Desktop 檔案時，此方法不需要 Fabric 容量或 Premium 授權。 不過，其確實涉及更多的設定工作和複雜度，因為您必須在 Power BI 之外管理部署。 已針對 Power BI 之外的資料解決方案使用 DevOps 的開發小組可能會熟悉此方法。 使用此方法的開發小組可以合併 Azure DevOps 中的資料解決方案部署。

使用 Fabric Git 整合進行部署

當您使用 Git 整合時，可以明確地將不同的分支同步至不同的工作區，而不是發佈或部署內容。 如此一來，您就可以有開發、測試和生產工作區的個別分支。 在此案例中，主要分支會與生產工作區同步。 然後，執行提取要求，將開發分支合併至測試分支 (部署至測試工作區)，或將測試分支合併至主要分支 (部署至生產工作區)，以在工作區之間部署內容。

下圖說明如何使用 Fabric Git 整合將分支同步至不同工作區以部署內容。 為求簡潔，圖表不包含分支或合併內容的詳細資料。

圖表顯示方法 5，也就是使用 Fabric Git 整合進行內容部署。接下來會說明圖表中的項目。

總而言之，內容建立者會認可內容變更，並將內容變更推送至 Azure Repos 中的遠端 Git 存放庫。 內容建立者會開啟提取要求 (PR)，要求將其變更合併至特定分支。 根據分支策略，不同的分支會連線到不同的工作區。 一旦變更合併至分支，內容建立者會將工作區與遠端 Git 存放庫同步，以檢視該工作區中內容的最新變更。

在下列情況下，請考慮此方法：

  • 您想要使用分支和合併策略來協調工作區之間的部署。
  • 您不打算使用 Azure Pipelines 或 Fabric 部署管線來協調部署以測試和生產環境。
  • 工作區不包含不支援的項目或案例。
  • 內容沒有敏感度標籤。

注意

有許多有效的方式可以部署內容。 例如，您可以使用本文所討論的不同方法組合。

例如，您可以使用 Azure Pipeline 將內容部署至開發工作區，這可讓您受益於持續整合功能並執行自動化測試 (例如使用最佳做法分析器)。 然後，您可以使用 Git 整合或 Fabric 部署管線，在工作區之間部署內容。

選擇最符合您需求的方法，以及小組的運作方式。

決定如何處理部署後的活動

部署之後，必須處理各種部署後活動。 其中許多活動都可以透過程式設計方式處理，例如由 Azure Pipeline 或筆記本以及 Power BI 和 Fabric REST API 來處理。 例如，您可以透過程式設計方式設定資料來源認證、管理排程的重新整理，以及在中繼資料部署之後觸發重新整理。 不過，某些工作需要手動介入，例如第一次設定或更新 Power BI 應用程式。

請確定您識別內容的所有相關部署後活動，並決定如何處理這些活動。

規劃如何部署內容之後，接下來應考慮如何支援和監視內容。

檢查清單 - 規劃部署內容的方式時，關鍵決策和動作包括：

  • 識別可供您使用的部署選項：視您的授權和內容而定，您將有不同的選項可供發佈內容，或在工作區之間將其升階。 識別您是否可以使用部署管線、Azure DevOps、Git 整合、Fabric REST API 和 XMLA 讀取/寫入端點。
  • 決定您將發佈內容的方式：選擇最適合您工作流程和需求的發佈內容方式。 請確定此方法符合其他策略，例如追蹤和管理變更的方式。
  • 決定如何在工作區之間升階內容：選擇將內容從開發部署到測試工作區，以及從測試部署到生產工作區的方法。 請確定此方法與您的其他策略一致，例如您將如何發佈內容。
  • 規劃您的發行策略：在核准發行或部署之前，判斷特定個人是否須負責內容的最終檢閱。 請確定此人員知道這項工作，以及其應執行哪些動作來保護部署程序，而不會妨礙進度。
  • 規劃部署後活動：確定您已決定執行活動的程序，例如在中繼資料部署之後更新 Power BI 應用程式或重新整理資料項目。 請考慮使用 Fabric REST API 將此程序自動化。
  • 執行第一次設定部署工具和程序：請確定您已設定適當的存取權，且該權限與您所設定內容的存取方式一致。
  • 將內容部署至生產環境：當您已規劃並設定部署時，請將內容部署至生產環境。

相關內容

在本系列的下一篇文章中，了解如何在管理內容生命週期時支援和監視內容。