持續整合和部署

8 分鐘

持續整合這個做法是自動且盡快測試對程式碼基底所做的每項變更。在持續整合期間執行測試，並將變更推送至暫存或生產系統後，就會進行持續傳遞。

在 Azure Data Factory 中，持續整合和傳遞 (CI/CD) 是指將一個環境 (開發、測試、生產) 中的 Data Factory 管線移至另一個環境。 Azure Data Factory 利用 Azure Resource Manager 範本來儲存各種 Azure Data Factory 實體 (管線、資料集、資料流程等等) 的設定。有兩個建議的方法可將資料處理站升級至另一個環境：

使用 Data Factory 與 Azure Pipelines 的整合進行自動化部署。
使用 Data Factory UX 與 Azure Resource Manager 整合以手動上傳 Resource Manager 範本。

持續整合/持續傳遞生命週期

以下是使用 Azure Repos Git 設定的 Azure 資料處理站中 CI/CD 生命週期的範例概觀。

開發資料處理站是使用 Azure Repos Git 進行建立及設定。所有開發人員都應該有權限撰寫 Data Factory 資源，例如管線和資料集。
開發人員會建立功能分支來進行變更。他們會使用最新的變更來對管線執行進行偵錯。
如果開發人員滿意其變更，便可從其功能分支建立對主要或共同作業分支的提取要求，讓同事檢閱其變更。
在核准提取要求並合併主要分支中的變更之後，變更就會發佈至開發處理站。
當小組準備好將變更部署到測試或 UAT (使用者驗收測試) 處理站時，小組會前往其 Azure Pipelines 發行，並將所需的開發處理站版本部署至 UAT。此部署會做為 Azure Pipelines 工作的一部分進行，並使用 Resource Manager 範本參數來套用適當的組態。
在測試處理站中驗證變更之後，請使用管線發行的下一個工作部署至生產工廠。

注意

只有開發處理站與 Git 存放庫相關聯。測試和生產工廠不應有與其相關聯的 Git 存放庫，且只能透過 Azure DevOps 管線或透過資源管理範本進行更新。

下圖醒目提示此生命週期的不同步驟。

Diagram of continuous integration with Azure Pipelines

使用 Azure Pipelines 發行將持續整合自動化

以下是設定 Azure Pipelines 發行的指南，可將資料處理站部署至多個環境自動化。

需求

使用 Azure Resource Manager 服務端點的 Azure Repos 或連結至 Visual Studio Team Foundation Server 的 Azure 訂閱。
使用 Azure Repos Git 整合設定的資料處理站。
包含每個環境的祕密的 Azure 金鑰保存庫。

設定 Azure Pipelines 發行

在 Azure DevOps 中，開啟使用資料處理站設定的專案。
在頁面左側，選取 [管線]，然後選取 [發行]。
選取 [新增管線]，或者，如果您有現有的管線，請選取 [新增] 然後選取 [新增發行管線]。
選取 [空白作業] 範本。
在 [暫存名稱] 方塊中，輸入環境的名稱。
選取 [新增成品]，然後選取使用開資料處理站設定的 Git 存放庫。選取 [預設分支] 存放庫的發佈分支。根據預設，此發佈分支為 adf_publish。針對 [預設版本]，選取 [預設分支中的最新版本]。
新增 Azure Resource Manager 部署工作：

a. 在暫存檢視中，選取 [檢視暫存工作]。

b. 建立新的工作。搜尋 ARM 範本部署，接著選取 [新增]。

c. 在 [部署] 工作中，選取目標資料處理站的訂用帳戶、資源群組和位置。視需要提供認證。

d. 在 [動作] 清單中，選取 [建立或更新資源群組]。

e. 選取 [範本] 方塊旁的省略號按鈕 (…)。瀏覽在已設定 Git 存放庫發佈分支中產生的 Azure Resource Manager 範本。在 adf_publish 分支的 <FactoryName> 資料夾中尋找 ARMTemplateForFactory.json 檔案。

f. 選取 [範本參數] 方塊旁的 […]，以選擇參數檔案。在 adf_publish 分支的 <FactoryName> 資料夾中尋找 ARMTemplateParametersForFactory.json 檔案。

.g 選取 [覆寫範本參數] 方塊旁的 […]，然後輸入目標資料處理站所需的參數值。針對來自 Azure Key Vault 的認證，請在雙引號之間輸入秘密的名稱。例如，如果秘密的名稱是 cred1，請針對此值輸入 "$(cred1)"。

h. 針對 [部署模式] 選取 [累加式]。

警告

在完整部署模式中，存在於資源群組中但未在新的 Resource Manager 範本中指定的資源將將遭到刪除。
儲存發行管線。
若要觸發發行，請選取 [建立發行]。在 Azure DevOps 中，這可以自動化。

重要

在 CI/CD 案例中，不同環境中的整合執行階段 (IR) 類型必須相同。例如，如果您在開發環境中具有自我裝載 IR，則相同的 IR 在其他環境 (例如測試和生產環境) 中的類型也必須為自我裝載。同樣地，如果您要跨多個階段共用整合運行時間，則必須將所有環境中的整合運行時間設定為連結的自我裝載，例如開發、測試和生產環境。

從 Azure Key Vault 取得秘密

如果您有秘密可傳入 Azure Resource Manager 範本，建議您搭配 Azure Pipelines 發行使用 Azure Key Vault。

有兩種方式可以處理秘密：

將秘密新增至參數檔案。

建立上傳至發佈分支的參數檔案複本。使用下列格式，設定您想要從 Key Vault 取得的參數值：

{
    "parameters": {
        "azureSqlReportingDbPassword": {
            "reference": {
                "keyVault": {
                    "id": "/subscriptions/<subId>/resourceGroups/<resourcegroupId> /providers/Microsoft.KeyVault/vaults/<vault-name> "
                },
                "secretName": " < secret - name > "
            }
        }
    }
}

當您使用此方法時，會自動從金鑰保存庫提取祕密。

參數檔案也必須位於發佈分支中。

在上一節所述的 Azure Resource Manager 部署工作之前新增 Azure Key Vault 工作：
1. 在 [工作] 索引標籤上，建立新的工作。搜尋 Azure Key Vault 並加以新增。
2. 在 Key Vault 工作中，選取您建立金鑰保存庫的訂用帳戶。視需要提供認證，然後選取金鑰保存庫。

將權限授與 Azure Pipelines 代理程式

如果未設定正確的權限，Azure Key Vault 工作可能會失敗，並出現拒絕存取錯誤。下載發行的記錄，並找出包含命令的 .ps1 檔案，以向 Azure Pipelines 代理程式授與權限。您可以直接執行命令。或者，您可以從檔案複製主體識別碼，並在 Azure 入口網站中手動新增存取原則。 Get 和 List 是所需的最低權限。

更新作用中的觸發程序

如果您嘗試更新作用中的觸發程序，部署可能會失敗。若要更新作用中的觸發程序，您必須手動停止觸發程序，然後在部署之後加以重新啟動。您可以使用 Azure PowerShell 工作來執行此動作：

在發行的 [工作] 索引標籤上，新增 Azure PowerShell 工作。選擇工作 4.*版。
選取包含您處理站的訂用帳戶。

選取 [指令檔路徑] 做為指令碼類型。這需要您將 PowerShell 指令碼儲存在存放庫中。下列 PowerShell 指令碼可用來停止觸發程序：

$triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $DataFactoryName -ResourceGroupName $ResourceGroupName

$triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.name -Force }

您可以完成類似的步驟 (使用 Start-AzDataFactoryV2Trigger 函式) 在部署之後重新啟動觸發程序。

注意

這些步驟已包含在 Azure Data Factory 小組所提供的部署前和部署後程式碼中

手動升級每個環境的 Resource Manager 範本

如果您無法使用 Azure DevOps 或不同的發行管理工具，您可以使用 ARM 範本以手動升級資料處理站。

在 [ARM 範本] 清單中，選取 [匯出 ARM 範本]，以在開發環境中匯出資料處理站的 Resource Manager 範本。
在您的測試和生產資料處理站中，選取 [匯入 ARM 範本]。此動作會帶您前往 Azure 入口網站，您可以在其中將匯出的範本匯入。選取 [在編輯器中建置您自己的範本] 以開啟 Resource Manager 範本編輯器。
選取 [載入檔案]，然後選取產生的 Resource Manager 範本。這是位於步驟 1 所匯出 .zip 檔案中的 arm_template.json 檔案。
在 [設定] 區段中，輸入組態值，例如連結服務認證。完成時，請選取 [購買] 以部署 Resource Manager 範本。

自訂 Azure Resource Manager 範本參數

如果您的開發處理站有相關聯的 Git 存放庫，您可以覆寫發佈或匯出範本所產生 Resource Manager 範本的預設 Resource Manager 範本參數。您可能需要在這些案例中覆寫預設參數化範本：

您可以使用自動化 CI/CD，並且要在 Resource Manager 部署期間變更某些屬性，但屬性預設不會參數化。
您的處理站過大導致預設 Resource Manager 範本無效，因為其超過允許的參數上限 (256)。

若要覆寫預設參數化範本，請前往管理中樞，並在原始檔控制區段中選取 [參數化範本]。選取 [編輯範本] 以開啟參數化範本程式碼編輯器。

Manage custom parameters

建立自訂參數化範本後，系統會自動在您的 git 分支的根資料夾中建立名為 arm-template-parameters-definition.json 的檔案。您必須使用該確切的檔案名稱。

Custom parameters file

從協作分支發佈時，Data Factory 會讀取此檔案，並使用其組態來產生哪些屬性會進行參數化。如果找不到任何檔案，則會使用預設範本。

匯出 Resource Manager 範本時，Data Factory 會從您目前正在處理的任何分支 (而不只是從協作分支) 讀取此檔案。您可以從私人分支建立或編輯檔案，您可以在其中選取 UI 中的 [匯出 ARM 範本] 來測試變更。然後，您可以將檔案合併至協作分支。

注意

自訂參數化範本不會變更 256 的 ARM 範本參數限制。其可讓您選擇及減少參數化屬性的數目。

自訂參數語法

以下是建立自訂參數檔案 arm-template-parameters-definition.json 時所要遵循的一些指導方針。檔案包含每個實體類型的區段：觸發程序、管線、連結服務、資料集、整合執行階段和資料流程。

在相關的實體類型下輸入屬性路徑。
將屬性名稱設定為 *，表示您希望將其下的所有屬性參數化 (僅限向下的第一層級，而非以遞迴方式)。您也可以提供此組態的例外狀況。
將屬性的值設定為字串，表示您想要將屬性參數化。使用 <action>:<name>:<stype> 的格式。
- <action> 可以是下列其中一個字元：
  - = 表示將目前的值保留作為參數的預設值。
  - - 表示不要保留參數的預設值。
  - | 是 Azure Key Vault 中連接字串或金鑰的祕密的特殊案例。
- <name> 是參數的名稱。如果空白，則會取得屬性的名稱。如果值是以 - 字元為開頭，則會縮短名稱。例如，AzureStorage1_properties_typeProperties_connectionString 會縮短為 AzureStorage1_connectionString。
- <stype> 是參數的類型。如果 <stype> 空白，則預設類型為 string。支援的值：string、bool、number、object 和 securestring。
在定義檔中指定陣列表示範本中的比對屬性為陣列。 Data Factory 會使用陣列整合執行階段物件中指定的定義，逐一查看陣列中的所有物件。第二個物件 (字串) 會成為屬性的名稱，該名稱會做為每個反覆項目的參數名稱。
定義不能專屬於資源執行個體。任何定義都會套用至該類型的所有資源。
根據預設，所有安全字串 (例如 Key Vault 秘密) 以及安全字串 (例如連接字串、金鑰和權杖) 都會參數化。

連結的範本

如果您已為資料處理站設定 CI/CD，可能會超過 Azure Resource Manager 範本限制，因為您的處理站變大。例如，一個限制是 Resource Manager 範本中的資源數目上限。為了在產生處理站的完整 Resource Manager 範本時容納大型處理站，Data Factory 現在會產生連結的 Resource Manager 範本。透過這項功能，整個處理站承載會細分成數個檔案，讓您不受限制所限。

如果您已設定 Git，則會產生連結的範本並與完整 Resource Manager 範本一起儲存在 adf_publish 分支中名為 linkedTemplates 的新資料夾中。連結的 Resource Manager 範本通常由主要範本和一組連結至主範本的子範本所組成。父範本稱為 ArmTemplate_master.json，而子範本會以 ArmTemplate_0.json、ArmTemplate_1.json 等這個模式來命名。

若要使用連結的範本，而不是完整的 Resource Manager 範本，請更新 CI/CD 工作以指向 ArmTemplate_master.json，而不是 ArmTemplateForFactory.json (完整的 Resource Manager 範本)。 Resource Manager 也需要您將連結的範本上傳至儲存體帳戶，讓 Azure 可以在部署期間加以存取。

Hotfix 實際執行環境

如果您將處理站部署至生產環境，並意識到有需要立即修正的錯誤，但您無法部署目前的協作分支，則可能需要部署 Hotfix。這種方法稱為快速修正工程或 QFE。

在 Azure DevOps 中，移至部署至生產環境的發行。尋找已部署的最後一個認可。
從認可訊息中，取得協作分支的認可識別碼。
從該認可建立新的 Hotfix 分支。
移至 Azure Data Factory UX，並切換至 Hotfix 分支。
使用 Azure Data Factory UX 來修正錯誤。測試您的變更。
驗證修正之後，請選取 [匯出 ARM 範本] 以取得 Hotfix Resource Manager 範本。
手動將此組建簽入 adf_publish 分支。
如果您已將發行管線設定為根據 adf_publish 簽入自動觸發，則新發行會自動啟動。否則，請手動將發行排入佇列。
將 Hotfix 發行部署至測試和生產處理站。此發行包含先前的生產承載加上您在步驟 5 中所做的修正。
將 Hotfix 的變更新增至開發分支，讓更新發行不會包含相同的錯誤。

持續整合/持續傳遞的最佳作法

如果您使用 Git 與資料處理站整合，並具有可將變更從開發移至測試、然後再移至生產環境的 CI/CD 管線，建議使用下列最佳做法：

Git 整合。僅使用 Git 整合設定您的開發資料處理站。測試和生產環境的變更會透過 CI/CD 進行部署，且不需要 Git 整合。
部署前和部署後指令碼。在 CI/CD 中的 Resource Manager 部署步驟之前，您需要先完成某些工作，例如停止及重新啟動觸發程序和執行清除。建議您在部署工作前後使用 PowerShell 指令碼。資料處理站小組已提供可在 Azure Data Factory CI/CD 文件分頁中使用的指令碼。
整合執行階段與共用。整合執行階段不會經常變更，且在 CI/CD 的所有階段中都類似。因此，Data Factory 預期您在 CI/CD 的所有階段都有相同的整合執行階段名稱和類型。如果您想要跨所有階段共用整合執行階段，請考慮只使用三元處理站來包含共用整合執行階段。您可以在所有環境中使用此共用處理站，做為連結整合執行階段類型。
受控私人端點部署。如果私人端點已經存在於處理站中，而您嘗試部署的 ARM 範本包含具有相同名稱但已修改屬性的私人端點，則部署將會失敗。換句話說，只要它的屬性與處理站中現有的名稱相同，您就可以成功部署私人端點。如果環境之間有不同的屬性，您可以將該屬性參數化，並在部署期間提供個別的值來覆寫它。
Key Vault。當您使用連線資訊儲存在 Azure Key Vault 中的連結服務時，建議針對不同的環境保留個別的金鑰保存庫。您也可以針對每個金鑰保存庫設定個別的權限等級。例如，您可能不希望小組成員擁有生產秘密的權限。如果您遵循此方法，建議您在所有階段中都保留相同的秘密名稱。如果您保留相同的秘密名稱，就不需要跨 CI/CD 環境參數化每個連接字串，因為唯一變更的項目是金鑰保存庫名稱，也就是個別參數。
資源命名：由於 ARM 範本有條件約束的緣故，您的資源如果在名稱中包含空格，則可能會發生部署問題。 Azure Data Factory 團隊建議在命名資源時使用「_」或「-」字元，而不使用空格。例如，「Pipeline_1」會是比「Pipeline 1」更理想的名稱。

繼續