Fabric 中生命週期管理的最佳做法
此文章可為使用 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 最佳做法是進行容易合並且不太可能發生衝突的小型累加變更。 如果做不到，請確定從主分支更新分支，以便先自己解決衝突。
組態變更：如有必要，請變更工作區中的組態，以協助您更高效地工作。 某些變更可能包括項目之間的連線，或與不同資料來源的連線或指定項目上參數的變更。 請記住，您認可的任何內容都會成為認可的一部分，而且可能會意外地合併到主分支中。
使用用戶端工具編輯工作
對於支援它的專案和工具，使用用戶端工具撰寫可能比較容易，例如 Power BI Desktop 的語意模型和報表、 適用於筆記本的 VS Code 等。這些工具可以是您的本機開發環境。 完成工作之後，請將變更推送至遠端存放庫，並同步工作區以上傳變更。 請確定您正在使用所製作項目的受支持結構。 如果您不確定，請先複製已同步內容至工作區的存放庫，然後從結構已就緒之處開始製作。
管理工作區和分支
由於工作區一次只能連線到單一分支，建議將此視為 1:1 對應。 不過，若要減少所需的工作區數量，請考慮下列選項：
如果開發人員使用所有必要的組態來設定私人工作區，他們可以針對他們建立的任何未來分支繼續使用該工作區。 短期衝刺結束後，您的變更會合併，如果您要開始新的工作，只須將連線切換至相同工作區上的新分支即可。 如果您突然需要在短期衝刺中間修正錯誤，您也可以這麼做。 將其視為 Web 上的工作目錄。
使用用戶端工具 (例如 VS Code、Power BI Desktop 或其他工具) 的開發人員不一定需要工作區。 他們可以在本機建立分支並認可該分支的變更、將這些分支推送至遠端存放庫，並建立對主分支的提取要求，所有動作都不需要工作區。 工作區只需要作為測試環境來檢查一切在真實案例中是否正常運作。 由您決定何時應該做這件事。
複製 Git 存放庫中的項目
若要複製 Git 存放庫中的項目：
- 複製整個項目目錄。
- 將 logicalId 變更為該連線工作區的唯一項目。
- 變更顯示名稱，使其與原始項目區別開來，並避免重複顯示名稱錯誤。
- 如有必要，請更新任何相依性中的 logicalId 和/或顯示名稱。
部署管線測試階段的最佳做法
此節提供有關使用部署管線測試階段的指導方針。
模擬您的生產環境
請務必了解建議的變更將如何影響生產階段。 部署管線測試階段可讓您模擬實際生產環境以供測試之用。 或者，您可以將 Git 連線至另一個工作區來模擬此環境。
請確定在您的測試環境中，已解決這三個因素：
資料量
使用量
與生產環境中類似的容量
測試時，您可以使用與生產階段相同的容量。 不過，使用相同的容量，可能會使生產環境在負載測試期間出現不穩定的狀況。 若要避免生產環境不穩定，請在資源中使用與生產容量類似的不同容量進行測試。 為避免產生額外的成本，請使用可讓您僅為測試期間付費的容量。
使用部署規則搭配實際資料來源
如果您使用測試階段來模擬實際資料使用量，建議將開發與測試資料來源分開。 開發資料庫應該相對較小，而測試資料庫應該盡可能類似生產資料庫。 使用資料來源規則在測試階段切換資料來源，或在未透過部署管線運作時參數化連線。
檢查相關項目
所做的變更也會影響相依項目。 在測試期間，請確認您的變更不會影響或中斷現有項目的效能，這可能相依於所更新的項目。
您可以使用影響分析，輕鬆地找到相關項目。
更新資料項目
資料項目是儲存資料的項目。 Git 中的項目定義會定義資料的儲存方式。 更新工作區中的項目時，我們會將其定義匯入工作區，並將它套用至現有的資料。 更新資料項目的作業與 Git 和部署管線的作業相同。
在套用定義變更時，不同的項目在保留資料方面有不同的功能，因此套用變更時請多加注意。 可協助您以最安全的方式套用變更的一些做法：
事先了解有哪些變更，以及變更可能對現有資料產生的影響。 使用認可訊息來描述所做的變更。
若要了解該項目如何使用測試資料來處理變更，請先將變更上傳至開發或測試環境。
如果一切順利，建議同時使用實際資料 (或盡可能接近實際資料的資料) 在預備環境中檢查變更，以便盡可能減少生產環境中的非預期行為。
請考慮更新 Prod 環境時的最佳時機，以將任何錯誤可能給使用資料的商務使用者造成的損害降到最低。
部署之後，透過 Prod 中的部署后測試，確認一切都如預期般運作。
某些變更一律會被視為中斷性變更。 希望上述步驟可協助您在生產之前追蹤它們。 建置計劃，確定如何套用 Prod 中的變更，並復原資料以回到正常狀態，將商務使用者的停機時間降到最低。
測試您的應用程式
如果您要透過應用程式將內容散發給使用者，請在應用程式進入生產環境之前，先檢閱其新版本。 由於每個部署管線階段都有自己的工作區，您可以針對開發與測試階段，輕鬆地發佈及更新應用程式。 發佈和更新應用程式可讓您從終端使用者的觀點測試應用程式。
重要
部署程序不包含更新應用程式內容或設定。 若要將變更套用至內容或設定，請在必要的管線階段手動更新應用程式。
部署管線生產階段的最佳做法
此節提供部署管線生產階段的指導方針。
管理可以部署到生產環境的人員
由於部署至生產環境時應謹慎處理，最好只讓特定人員管理這種敏感作業。 不過，您可能想要使特定工作區的所有 BI 建立者都能夠存取管線。 使用生產工作區權限來管理存取權限。 其他使用者可以透過生產工作區檢視人員角色來查看工作區中的內容，但無法從 Git 或部署管線進行變更。
此外，應只為屬於內容建立程序一部分的使用者啟用管線權限，以限制對存放庫或管線的存取。
設定規則以確保生產階段的可用性
部署規則是確保生產環境中的資料一律已連線且可供使用者使用的有效方式。 套用部署規則後，即可執行部署，同時確保客戶可在沒有擾亂的情況下看見相關資訊。
請確定您為語義模型內定義的資料來源與參數設定了生產部署規則。
更新生產應用程式
透過 UI 在管線中部署會更新工作區內容。 若要更新相關聯的應用程式，請使用部署管線 API。 無法透過 UI 更新應用程式。 如果您使用應用程式進行內容發佈，請記得在部署至生產環境之後更新應用程式，讓終端使用者即刻就能使用最新版本。
使用 Git 分支部署到生產環境
由於存放庫可作為「單一事實來源」，某些團隊可能會想要直接從 Git 將更新部署到不同的階段。 這可以透過 Git 整合實現，但需要注意一些事項：
我們建議使用發行分支。 您需要在每次部署之前，持續更改工作區與新發行分支的連線。
如果建置或發行管線要求更改原始程式碼，或先在建置環境中執行腳本，再部署至工作區，則將工作區連線到 Git 將無濟於事。
部署至每個階段之後，請確定更改該階段特有的所有組態。
快速修正內容
有時，生產環境會有需要快速修正的問題。 部署修正程式而不先進行測試是不好的做法。 因此，請一律在開發階段實作修正程式，並將其推送至其餘的部署管線階段。 部署至開發階段，可讓您先檢查修正程式是否妥善運作，再將其部署至生產環境。 在整個管線中進行部署只需幾分鐘的時間。
如果使用 Git 的部署，建議遵循＜採用 Git 分支策略＞中所述的做法。