共用方式為

為您選擇最佳的網狀架構 CI/CD 工作流程選項

  • 發行項

本文的目標是根據常見的客戶案例，向網狀架構開發人員呈現在 Fabric 中建置 CI/CD 程式的不同選項。 本文更著重於 CI/CD 程式的持續部署 （CD）。 如需持續整合 （CI） 部分的討論，請參閱管理 Git 分支。

雖然本文概述數個不同的選項，但許多組織都採用混合式方法。

必要條件

要存取部署管線功能，您必須符合下列條件：

開發流程

在所有部署案例中，開發程式都相同，且與如何將新的更新發行至生產環境無關。 當開發人員使用原始檔控制時，他們需要在隔離的環境中工作。 在 Fabric 中，該環境可以是本機電腦上的 IDE（例如 Power BI Desktop 或 VS Code），或 Fabric 中的不同工作區。 您可以在管理 Git 分支中找到 開發程式之不同考慮的相關信息

顯示開發程序運作方式的圖表。

發行程序

發行程式會在新的更新完成之後開始，並將提取要求 （PR） 合併至小組的共用分支（例如 Main、 Dev 等）。 此時，在 Fabric 中建置發行程式有不同的選項。

選項 1 - Git 型部署

顯示 Git 型部署運作方式的圖表。

使用此選項時，所有部署都是來自 Git 存放庫。 發行管線中的每個階段都有專用的主要分支（在圖表中，這些階段為 Dev、 Test 和 Prod），它會在 Fabric 中提供適當的工作區。

一旦核准並合併開發分支的 PR：

  1. 發行管線會觸發以更新開發人員工作區的內容。 此程式也可以包含 建 置管線來執行單元測試，但實際上傳的檔案會使用 Fabric Git API 直接從存放庫上傳至工作區。 您可能需要呼叫其他網狀架構 API 來進行部署後作業，以設定此工作區的特定組態，或內嵌數據。
  2. 接著會建立PR至 測試 分支。 在大部分情況下，會使用發行分支來建立PR，以挑選要移至下一個階段的內容。 PR 應包含與小組或組織中任何其他人員相同的檢閱和核准程式。
  3. 另一個 建置 和 發行 管線會觸發來更新 測試 工作區，其程式與第一個步驟中所述的程序類似。
  4. PR 會使用類似於步驟 2 中所述的程式，建立至 Prod 分支。
  5. 另一個 建 置和 發行 管線會觸發來更新 Prod 工作區，其程式與第一個步驟中所述的程序類似。

何時應該考慮使用選項 #1？

  • 當您想要使用 Git 存放庫作為單一事實來源，以及所有部署的來源時。
  • 當小組遵循 Gitflow 作為分支策略時，包括多個主要分支。
  • 從存放庫上傳會直接進入工作區，因為我們不需要 建置環境 才能在部署之前改變檔案。 您可以在部署後呼叫 API 或執行工作區中的項目來變更此專案。

選項 2 - 使用建置環境的 Git 型部署

顯示使用建置環境之 Git 型部署流程的圖表。

使用此選項時，所有部署都是來自 Git 存放庫 （Main） 的相同分支。 發行管線中的每個階段都有專用 的組建 和 發行 管線。 這些管線可能會使用 建置環境 來執行單元測試和腳本，這些腳本會在專案上傳至工作區之前，先變更專案中的某些定義。 例如，您可能想要變更數據源連線、工作區中專案之間的連接，或參數的值來調整正確階段的組態。

一旦核准並合併開發分支的 PR：

  1. 會觸發組建管線來啟動新的組建環境，並執行開發階段的單元測試。 然後， 會觸發發行 管線將內容上傳至 組建環境、執行腳本來變更部分設定、將設定調整為 開發 階段，並使用 Fabric 的 更新專案定義 API 將檔案上傳至工作區。
  2. 完成此程式時，包括從發行管理員擷取數據和核准，即可建立測試階段的下一個組建和發行管線。 這些階段是在與第一個步驟中所述類似的程式中建立的。 針對 測試 階段，部署之後可能需要其他自動化或手動測試，以驗證變更已準備好發行至 Prod 階段。
  3. 當所有自動化和手動測試都完成時，發行管理員就可以核准並啟動 組建 和 發行 管線至 Prod 階段。 由於 Prod 階段的設定通常與測試/開發階段不同，因此請務必在部署之後測試變更。 此外，部署應該根據變更觸發更多數據擷取，以將取用者的潛在非可用性降到最低。

何時應該考慮使用選項 #2？

  • 當您想要使用 Git 作為單一事實來源，以及所有部署的來源時。
  • 當小組遵循 主幹型 工作流程做為其分支策略時。
  • 在部署之前，您需要建置環境（使用自定義腳本）來變更工作區特定的屬性，例如 connectionId 和 lakehouseId。
  • 您需要發行管線（自定義腳本）從 git 擷取項目內容，並呼叫對應的 網狀架構專案 API ，以建立、更新或刪除已修改的網狀架構專案。

選項 3 - 使用網狀架構部署管線進行部署

顯示使用部署管線之 Git 型部署流程的圖表。

使用此選項時，Git 只會連線到 開發 階段。 從開發階段，使用網狀架構部署管線，直接在開發/測試/Prod 工作區之間進行部署。 雖然此工具本身是 Fabric 內部，但開發人員可以使用 部署管線 API ，將部署協調為其 Azure 發行管線或 GitHub 工作流程的一部分。 這些 API 可讓小組建立類似其他選項的組建和發行程式，方法是使用自動化測試（可在工作區本身或開發階段之前完成）、核准等。

核准並合併主要分支的PR之後：

  1. 會觸發建置管線，使用 Fabric Git API 將變更上傳至開發階段。 如有必要，管線可以觸發其他 API，以在開發階段啟動部署後作業/測試。
  2. 開發部署完成後，發行管線會開始部署從開發階段到測試階段的變更。 部署之後應該進行自動化和手動測試，以確保變更在到達生產環境之前經過良好測試。
  3. 測試完成且發行管理員核准部署至 Prod 階段之後，Prod 的發行就會開始並完成部署。

何時應考慮使用選項 #3？

  • 當您只針對開發目的使用原始檔控制時，偏好直接在發行管線的階段之間部署變更。
  • 當部署規則時，自動系結和其他可用的 API 就足以管理發行管線階段之間的設定。
  • 當您想要使用 Fabric 部署管線的其他功能時，例如檢視網狀架構中的變更、部署歷程記錄等。
  • 也請考慮 Fabric 部署管線中的部署具有線性結構，而且需要其他許可權來建立和管理管線。

選項 4 - Fabric 中 ISV 的 CI/CD （管理多個客戶/解決方案）

此圖顯示ISV的 Git 型部署流程。

此選項與其他選項不同。 與獨立軟體供應商 （ISV） 最相關，他們會在 Fabric 之上為客戶建置 SaaS 應用程式。 ISV 通常每個客戶都有個別的工作區，而且可以有多達數百個或數千個工作區。 當提供給每位客戶的分析結構類似且現成時，我們建議使用集中的開發與測試程式，而此程式只會在 Prod 階段中分割給每位客戶。

此選項是以選項 #2 為基礎。 一旦核准並合併主要的PR：

  1. 會觸發組建管線來啟動新的組建環境，並執行開發階段的單元測試。 測試完成時， 會觸發發行 管線。 此管線可以將內容上傳至 組建環境、執行腳本來變更部分設定、將設定調整為 開發 階段，然後使用 Fabric 的 更新專案定義 API 將檔案上傳至工作區。
  2. 完成此程序之後，包括從發行管理員擷取數據和核准，測試階段的下一個組建和發行管線就可以開始。 此程式類似於第一個步驟中所述的程式。 針對 測試 階段，部署之後可能需要其他自動化或手動測試，以驗證變更已準備好以高質量發行至 Prod 階段。
  3. 一旦所有測試都通過並核准程式完成之後，對 Prod 客戶的部署就可以開始。 每位客戶都有自己的版本及其參數，因此其特定組態和數據連線可以在相關的客戶工作區中進行。 組態變更可以透過建置環境中的腳本，或使用部署後的 API 進行。 所有版本都可以平行發生，因為它們彼此無關，也不相依。

何時應該考慮使用選項 #4？

  • 您是在 Fabric 之上建置應用程式的 ISV。
  • 您針對每位客戶使用不同的工作區來管理應用程式的多租使用者
  • 如需更多區隔，或針對不同客戶的特定測試，您可能想要在開發或測試的早期階段擁有多租使用者。 在此情況下，請考慮使用多租使用者時，所需的工作區數目會大幅增加。

摘要

本文摘要說明想要在 Fabric 中建置自動化 CI/CD 程式之小組的主要 CI/CD 選項。 雖然我們概述四個選項，但現實生活中的條件約束和解決方案架構可能適合混合式選項，或完全不同的選項。 您可以使用本文來引導您完成不同的選項，以及如何建置這些選項，但您不強制只選擇其中一個選項。

某些案例或特定專案可能會有 限制 ，讓您無法採用上述任何案例。

工具也是如此。 雖然我們在這裡提到不同的工具，但您可以選擇提供相同層級功能的其他工具。 請考慮 Fabric 與某些工具有較佳的整合，因此選擇其他工具會產生更多需要不同因應措施的限制。

相關內容