Azure Data Factory 中的持續整合和傳遞
適用于： 
Azure Data Factory 
Azure Synapse Analytics
提示
試用 Microsoft Fabric 中的 Data Factory，這是適用于企業的單一分析解決方案。 Microsoft Fabric 涵蓋從資料移動到資料科學、即時分析、商業智慧和報告等所有專案。 瞭解如何 免費啟動新的試用版 ！
持續整合這個做法是自動且盡快測試對程式碼基底所做的每項變更。 在持續整合期間執行測試，並將變更推送至暫存或生產系統後，就會進行持續傳遞。
在 Azure Data Factory 中，持續整合和傳遞 (CI/CD) 是指將一個環境 (開發、測試、生產) 中的 Data Factory 管線移至另一個環境。 Azure Data Factory 會 利用 Azure Resource Manager 範本 來儲存各種 ADF 實體的設定（管線、資料集、資料流程等等）。 有兩個建議的方法可將資料處理站升級至另一個環境：
- 使用 Data Factory 與 Azure Pipelines 整合進行自動化部署
- 使用 Data Factory UX 與 Azure Resource Manager 整合以手動上傳 Resource Manager 範本。
注意
建議您使用 Azure Az PowerShell 模組來與 Azure 互動。 請參閱安裝 Azure PowerShell 以開始使用。 若要了解如何移轉至 Az PowerShell 模組，請參閱將 Azure PowerShell 從 AzureRM 移轉至 Az。
CI/CD 生命週期
注意
如需詳細資訊，請參閱 持續部署改善 。
以下是使用 Azure Repos Git 設定的 Azure 資料處理站中 CI/CD 生命週期的範例概觀。 如需如何設定 Git 存放庫的詳細資訊，請參閱 Azure Data Factory 中的原始檔控制。
開發資料處理站是使用 Azure Repos Git 進行建立及設定。 所有開發人員都應該有權限撰寫 Data Factory 資源，例如管線和資料集。
開發人員 會建立功能分支 來進行變更。 他們會使用最新的變更來對管線執行進行偵錯。 如需如何偵錯管線執行的詳細資訊，請參閱 使用 Azure Data Factory 反復開發和偵錯。
開發人員滿意其變更之後，他們會從其功能分支建立提取要求至主要或共同作業分支，以取得對等檢閱的變更。
在核准提取要求併合並主要分支中的變更之後，變更就會發佈至開發處理站。
當小組準備好將變更部署到測試或 UAT (使用者驗收測試) 處理站時，小組會前往其 Azure Pipelines 發行，並將所需的開發處理站版本部署至 UAT。 此部署會做為 Azure Pipelines 工作的一部分進行，並使用 Resource Manager 範本參數來套用適當的組態。
在測試處理站中驗證變更之後，請使用管線發行的下一個工作部署至生產工廠。
注意
只有開發處理站與 Git 存放庫相關聯。 測試和生產工廠不應有與其相關聯的 Git 存放庫，且只能透過 Azure DevOps 管線或透過資源管理範本進行更新。
下圖醒目提示此生命週期的不同步驟。
CI/CD 的最佳做法
如果您使用 Git 與資料處理站整合，並具有可將變更從開發移至測試、然後再移至生產環境的 CI/CD 管線，建議使用下列最佳做法：
Git 整合。 僅使用 Git 整合設定您的開發資料處理站。 測試和生產環境的變更會透過 CI/CD 進行部署，且不需要 Git 整合。
部署前和部署後指令碼。 在 CI/CD 中的 Resource Manager 部署步驟之前，您需要先完成某些工作，例如停止及重新啟動觸發程序和執行清除。 建議您在部署工作前後使用 PowerShell 指令碼。 如需詳細資訊，請參閱 更新使用中的觸發程式 。 資料處理站小組已 提供腳本 ，以用於此頁面底部。
警告
請務必在 ADO 工作中使用 PowerShell Core 來執行腳本。
警告
如果您未使用最新版本的 PowerShell 和 Data Factory 模組，在執行命令時可能會發生還原序列化錯誤。
整合執行階段與共用。 整合執行階段不會經常變更，且在 CI/CD 的所有階段中都類似。 因此，Data Factory 預期您在 CI/CD 的所有階段都有相同的名稱、類型和子類型整合執行時間。 如果您想要跨所有階段共用整合執行階段，請考慮只使用三元處理站來包含共用整合執行階段。 您可以在所有環境中使用此共用處理站，做為連結整合執行階段類型。
注意
整合執行時間共用僅適用于自我裝載整合執行時間。 Azure-SSIS 整合執行時間不支援共用。
受控私人端點部署。 如果私人端點已經存在於處理站中，而您嘗試部署的 ARM 範本包含具有相同名稱但已修改屬性的私人端點，則部署將會失敗。 換句話說，只要它的屬性與處理站中現有的名稱相同，您就可以成功部署私人端點。 如果環境之間有不同的屬性，您可以將該屬性參數化，並在部署期間提供個別的值來覆寫它。
Key Vault。 當您使用連線資訊儲存在 Azure Key Vault 中的連結服務時，建議針對不同的環境保留個別的金鑰保存庫。 您也可以針對每個金鑰保存庫設定個別的權限等級。 例如，您可能不希望小組成員擁有生產秘密的權限。 如果您遵循此方法，建議您在所有階段中都保留相同的秘密名稱。 如果您保留相同的秘密名稱，就不需要跨 CI/CD 環境參數化每個連接字串，因為唯一變更的項目是金鑰保存庫名稱，也就是個別參數。
資源命名 。 由於 ARM 範本條件約束，如果您的資源包含名稱中的空格，部署中可能會發生問題。 Azure Data Factory 團隊建議在命名資源時使用「_」或「-」字元，而不使用空格。 例如，「Pipeline_1」會是比「Pipeline 1」更理想的名稱。
改變存放庫 。 ADF 會自動管理 GIT 存放庫內容。 將手動不相關的檔案或資料夾變更或新增至 ADF Git 存放庫資料檔案夾中的任何位置，可能會導致資源載入錯誤。 例如，存在 .bak 檔案可能會導致 ADF CI/CD 錯誤，因此應該移除 ADF 載入。
曝光控制和功能旗標 。 在小組中工作時，有一些您可以合併變更的實例，但不希望他們在提升許可權的環境中執行，例如 PROD 和 QA。 為了處理此案例，ADF 小組建議 使用功能旗標 的 DevOps 概念。 在 ADF 中，您可以結合 全域參數 和 if 條件活動 ，以根據這些環境旗標隱藏邏輯集。
若要瞭解如何設定功能旗標，請參閱下列影片教學課程：
不支援的功能
根據設計，Data Factory 不允許挑選認可或選擇性發佈資源。 發佈會包含資料處理站中所做的所有變更。
- 資料處理站實體彼此相依。 例如，觸發程式相依于管線，而管線則相依于資料集和其他管線。 選擇性發佈資源子集可能會導致非預期的行為和錯誤。
- 當您需要選擇性發佈時，請考慮使用 Hotfix。 如需詳細資訊，請參閱 Hotfix 生產環境 。
Azure Data Factory 小組不建議將 Azure RBAC 控制項指派給資料處理站中的個別實體（管線、資料集等）。 例如，如果開發人員有管線或資料集的存取權，他們應該能夠存取資料處理站中的所有管線或資料集。 如果您覺得需要在資料處理站內實作許多 Azure 角色，請參閱部署第二個資料處理站。
您無法從私人分支發佈。
您目前無法在 Bitbucket 上裝載專案。
您目前無法匯出和匯入警示和矩陣做為參數。
在adf_publish 分支下 的程式碼存放庫中，目前會在 'linkedTemplates' 資料夾、'ARMTemplateForFactory.json' 和 'ARMTemplateParametersForFactory.json' 檔案旁邊新增名為 'PartialArmTemplates' 的資料夾，作為原始檔控制發行的一部分。
從 2021 年 11 月 1 日至 11 月，我們將不再發佈 'PartialArmTemplates' 至 adf_publish 分支。
除非您使用 'PartialArmTemplates'，否則不需要採取任何動作。 否則，請使用：'ARMTemplateForFactory.json' 或 'linkedTemplates' 檔案切換到任何支援的部署機制。