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 指令碼。 如需詳細資訊，請參閱更新使用中的觸發程序。 資料處理站小組已提供可用的指令碼 (位於此頁面的底部)。
注意
在持續整合與持續傳遞期間，如果您只要關閉/開啟已修改的觸發程序，而不是關閉/開啟所有觸發程序，請使用 PrePostDeploymentScript.Ver2.ps1。
警告
請務必在 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。
曝光控制項及功能旗標。 在小組中工作時，會出現可能需要合併變更，但不想要在生產和 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 日開始，我們不再將 'PartialArmTemplates' 發佈至 adf_publish 分支。
除非您正在使用 'PartialArmTemplates'，否則不需要採取任何動作。 否則，請使用：'ARMTemplateForFactory.json' 或 'linkedTemplates' 檔案切換到任何支援的部署機制。