生命週期管理最佳做法

本文提供在 Microsoft Fabric 中管理其內容之數據和分析建立者的指引。 本文著重於將 Git 整合 用於原始檔控制和 部署管線 作為發行工具。 如需企業內容發佈、 企業內容發佈的一般指引。

重要

這項功能處於預覽狀態。

本文分成四個區段：

• 內容準備 - 準備您的內容以進行生命週期管理。

• 開發 - 瞭解在部署管線開發階段中建立內容的最佳方式。

• 測試 - 瞭解如何使用部署管線測試階段來測試您的環境。

• 生產 - 利用部署管線生產階段，讓您的內容可供取用。

內容準備

若要在您的整個生命週期中為進行管理準備內容，請先檢閱本節中的資訊，再行檢閱：

• 將內容發行至生產環境。

• 開始針對特定工作區使用部署管線。

小組之間的個別開發

組織中的不同小組通常有不同的專業知識、擁有權和工作方法，即使處理相同的專案也一樣。 請務必設定界限，同時讓每個團隊都能像他們一樣獨立工作。 請考慮為不同的小組使用不同的工作區。 透過不同的工作區，每個小組都可以有不同的許可權、使用不同的原始檔控制存放庫，並以不同的步調將內容寄送至生產環境。 大部分的專案都可以跨工作區連線和使用數據，因此不會封鎖相同數據和專案上的共同作業。

規劃您的許可權模型

Git 整合和部署管線都需要與工作區許可權不同的許可權。 閱讀 Git 整合和部署管線的許可權需求。

若要實作安全且簡單的工作流程，請規劃誰能夠存取所使用環境的每個部分，Git 存放庫和管線中的開發/測試/生產階段。 要考慮的一些考慮包括：

• 神秘 應該可以存取 Git 存放庫中的原始程式碼？

• 具有管線存取權的用戶應該能夠在每個階段中執行哪些作業？

• 在測試階段 神秘 檢閱內容嗎？

• 測試階段檢閱者是否可存取管線？

• 神秘 應該監督生產階段的部署？

• 您要指派給管線或連線至 Git 的工作區？

• 您要將工作區連線到哪一個分支？ 該分支所定義的原則為何？

• 工作區是否由多個小組成員共用？ 他們應該直接在工作區中進行變更，還是只透過提取要求進行變更？

• 您要將工作區指派給哪個階段？

• 您需要變更您要指派之工作區的許可權嗎？

將不同階段 連線 至不同的資料庫

生產資料庫應該一律穩定且可供使用。 最好不要使用 BI 建立者為其開發或測試語意模型所產生的查詢多載。 建置不同的資料庫以進行開發和測試，以保護生產數據，而不是使用整個生產數據量多載開發資料庫。

針對將在階段之間變更的組態使用參數

盡可能將參數新增至任何可能在開發/測試/生產階段之間變更的定義。 當您將變更移至生產環境時，使用參數可協助您輕鬆地變更定義。 雖然在 Fabric 中仍然沒有統一管理參數的方式，但建議您在支援任何類型的參數化專案上使用它。 參數有不同的用途，例如定義數據源的連線，或定義 Fabric 中的內部專案。 它們也可以用來對用戶顯示的查詢、篩選和文字進行變更。
在部署管線中，您可以設定參數規則，為每個部署階段設定不同的值。

部署

本節提供使用部署管線，並使用適合您開發階段的指引。

將工作備份到 Git 存放庫

透過 Git 整合，任何開發人員都可以將工作認可至 Git 來備份其工作。 若要在 Fabric 中正確備份您的工作，以下是一些基本規則：

• 請確定您有隔離的環境可運作，因此其他人不會在認可工作之前覆寫您的工作。 這表示在桌面工具中工作（例如 VS Code、 Power BI Desktop 或其他工具），或在其他使用者無法存取的個別工作區中工作。

• 認可至您所建立的分支，且沒有其他開發人員正在使用。 如果您使用工作區作為撰寫環境，請閱讀 使用分支的相關信息。

• 一起認可必須一起部署的變更。 此建議適用於單一專案，或與相同變更相關的多個專案。 將所有相關變更一起認可可協助您稍後部署至其他階段、建立提取要求或還原變更。

• 大型認可可能會達到認可大小上限。 請留意您一起認可的項目數目，或專案的一般大小。 例如，新增大型影像時，報表可能會成長很大。 將大型專案儲存在原始檔控制系統中是不正確的做法，即使運作正常也一樣。 如果專案有許多靜態資源，例如影像，請考慮減少專案大小的方法。

回復變更

備份工作之後，在某些情況下，您可能會想要還原為舊版，並在工作區中還原。 有幾種方式可以還原為舊版：

• 復原按鈕： 復原 作業是一種簡單且快速的方式，只要尚未認可，即可還原您所做的立即變更。 您也可以個別復原每個專案。 深入了解 復原 作業。

• 還原為舊版認可：沒有直接方法可以回到UI中的先前認可。 最佳選項是使用 git revert 或 git reset 將較舊的認可升階為 HEAD。 這樣做會顯示原始檔控制窗格中有更新，而且您可以使用該新認可來更新工作區。

由於數據不會儲存在 Git 中，請記住，將數據項還原為舊版可能會中斷現有的數據，而且可能需要您卸除數據，否則作業可能會失敗。 在還原變更之前，請先確認這一點。

使用「私人」工作區

當您想要隔離工作時，請使用個別工作區作為隔離的環境。 深入瞭解如何在使用分支時隔離您的工作環境。 針對您和小組的最佳工作流程，請考慮下列幾點：

• 設定工作區：開始之前，請確定您可以建立新的工作區（如果您還沒有工作區），您可以將它指派給 Fabric 容量，而且您可以存取數據以在工作區中工作。

• 建立新的分支：從主要分支建立新的分支，因此您擁有最新版的內容。 此外，請確定您連線到分支中的正確資料夾，以便將正確的內容提取至工作區。

• 小型、頻繁的變更：Git 最佳做法是進行容易合並且不太可能發生衝突的小型累加變更。 如果不可能，請務必從main更新分支，以便先解決自己的衝突。

• 組態變更：如有必要，請變更工作區中的設定，以協助您更有生產力地工作。 某些變更可能包括專案之間的連線，或與不同的數據源或指定專案上參數的變更。 請記住，您認可的任何專案都會成為認可的一部分，而且可能會意外地合併到主要分支中。

使用用戶端工具編輯您的工作

對於支援它的專案和工具，使用用戶端工具撰寫可能比較容易，例如 適用於語意模型和報表的 Power BI Desktop 、 Notebook 的 VSCode 等。這些工具可以是您的本機開發環境。 完成工作之後，請將變更推送至遠端存放庫，並同步處理工作區以上傳變更。 請確定您正在處理 所撰寫專案的受支持結構 。 如果您不確定，請先複製已同步內容至工作區的存放庫，然後從該處開始撰寫結構已就緒。

管理工作區和分支

由於工作區一次只能連線到單一分支，因此建議將此視為 1：1 對應。 不過，若要減少所需的工作區數量，請考慮下列選項：

• 如果開發人員使用所有必要的設定來設定私人工作區，他們可以針對他們建立的任何未來分支繼續使用該工作區。 當短期衝刺結束時，您的變更會合併，而您正在開始新的工作，只要將連線切換至相同工作區上的新分支即可。 如果您突然需要在短期衝刺中間修正 Bug，您也可以這麼做。 將其視為網路上的工作目錄。

• 使用用戶端工具的開發人員（例如 VS Code、Power BI Desktop 或其他工具），不一定需要工作區。 他們可以在本機建立分支並認可該分支的變更、將這些分支推送至遠端存放庫，並將提取要求建立至主要分支，而不需要工作區。 只有測試環境需要工作區，才能檢查一切在真實案例中是否正常運作。 由您決定何時應該發生。

複製 Git 存放庫中的專案

若要複製 Git 存放庫中的專案：

1. 複製整個項目目錄。
2. 將logicalId變更為該連線工作區的唯一專案。
3. 變更顯示名稱，使其與原始項目區別，並避免重複顯示名稱錯誤。
4. 如有必要，請更新任何相依性中的logicalId和/或顯示名稱。

Test

本節提供使用部署管線測試階段的指引。

模擬生產環境

請務必瞭解您建議的變更將如何影響生產階段。 部署管線測試階段可讓您模擬實際生產環境以供測試之用。 或者，您可以將 Git 連線至另一個工作區來模擬此專案。

請確定測試環境中已解決這三個因素：

• 資料量

• 使用量

• 與生產環境類似的容量

測試時，您可以使用與生產階段相同的容量。 不過，使用相同的容量，在負載測試期間，生產環境可能會不穩定。 若要避免不穩定的生產，請使用與產能類似的資源中的不同容量進行測試。 若要避免額外費用，請使用容量，讓您可以只支付測試時間的費用。

搭配實際數據源使用部署規則

如果您使用測試階段來模擬實際數據使用量，最好將開發和測試數據源分開。 開發資料庫應該相對較小，而且測試資料庫應該儘可能類似於生產資料庫。 使用 數據源規則 在測試階段切換數據源，或在未透過部署管線運作時參數化連線。

檢查相關專案

您所做的變更也會影響相依專案。 在測試期間，請確認您的變更不會影響或中斷現有專案的效能，這可能取決於更新的專案。

您可以使用影響分析，輕鬆地找到相關專案。

更新數據項

數據項是儲存數據的專案。 Git 中的項目定義會定義資料的儲存方式。 更新工作區中的專案時，我們會將其定義匯入工作區，並將它套用至現有的數據。 更新數據項的作業與 Git 和部署管線相同。

由於不同的專案在套用定義變更時保留數據時有不同的功能，因此在套用變更時請注意。 可協助您以最安全的方式套用變更的一些做法：

• 事先瞭解變更是什麼，以及其可能對現有數據的影響。 使用認可訊息來描述所做的變更。

• 若要查看該專案如何處理測試數據的變更，請先將變更上傳至開發或測試環境。

• 如果一切順利，建議您在預備環境中檢查它，並盡可能接近實際數據，以將生產環境中的非預期行為降到最低。

• 請考慮更新 Prod 環境時的最佳時機，以將任何錯誤可能造成的損害降到最低，讓取用數據的企業用戶損失降到最低。

• 部署之後，Prod 中的部署后測試，以確認一切都如預期般運作。

• 某些變更一律會被視為 重大變更。 希望上述步驟可協助您在生產環境之前追蹤它們。 建置計劃，瞭解如何套用 Prod 中的變更，並復原數據以回到正常狀態，並將商務使用者的停機時間降到最低。

測試您的應用程式

如果您要透過應用程式將內容發佈給客戶，請在應用程式處於生產環境中之前，檢閱應用程式的新版本。 由於每個部署管線階段都有自己的工作區，因此您可以輕鬆地發佈和更新開發與測試階段的應用程式。 發佈和更新應用程式可讓您從使用者的觀點測試應用程式。

重要

部署程式不包含更新應用程式內容或設定。 若要將變更套用至內容或設定，請在必要的管線階段手動更新應用程式。

實際執行環境

本節提供部署管線生產階段的指引。

管理誰可以部署到生產環境

由於部署至生產環境應該謹慎處理，因此最好只讓特定人員管理此敏感性作業。 不過，您可能希望特定工作區的所有BI建立者都能存取管線。 使用生產 工作區許可權 來管理訪問許可權。 其他使用者可以有生產工作區 查看器 角色來查看工作區中的內容，但無法從 Git 或部署管線進行變更。

此外，只對屬於內容建立程式一部分的使用者啟用許可權，以限制對存放庫或管線的存取。

設定規則以確保生產階段可用性

部署規則 是一種強大的方式，可確保生產環境中的數據一律已連線並可供使用者使用。 套用部署規則時，部署可以執行，同時保證客戶可以在不干擾的情況下看到相關信息。

請確定您已為語意模型中定義的數據源和參數設定生產部署規則。

更新生產應用程式

透過UI在管線中部署會更新工作區內容。 若要更新相關聯的應用程式，請使用 部署管線 API。 無法透過 UI 更新應用程式。 如果您使用應用程式進行內容發佈，請記得在部署至生產環境之後更新應用程式，讓用戶能夠立即使用最新版本。

使用 Git 分支部署到生產環境

由於存放庫可作為「單一事實來源」，某些小組可能會想要直接從 Git 將更新部署到不同的階段。 這是 Git 整合的可能，但有一些考慮：

• 我們建議使用發行分支。 您必須在每次部署之前，持續將工作區的連線變更至新的發行分支。

• 如果您的組建或發行管線要求您變更原始程式碼，或先在組建環境中執行腳本，再部署至工作區，則將工作區連線到 Git 將無濟於事。

• 部署至每個階段之後，請務必變更該階段特有的所有設定。

內容的快速修正

有時候生產環境中有需要快速修正的問題。 部署修正程式而不先進行測試是錯誤的作法。 因此，請一律在開發階段實作修正，並將它推送至其餘的部署管線階段。 部署至開發階段可讓您先檢查修正程式是否正常運作，再將其部署到生產環境。 跨管線部署只需要幾分鐘的時間。

如果您使用 Git 的部署，建議您遵循採用 Git 分支策略中所述的作法。

相關內容

• 端對端生命週期管理教學課程
• 開始使用 Git 整合
• 開始使用部署管線