共用方式為


Azure Synapse Analytics 工作區的持續整合與傳遞

持續整合 (CI) 程序會在每次小組成員認可版本控制的變更時,自動建置和測試程式碼。 持續傳遞 (CD) 程序則會進行從多個測試或預備環境到生產環境的建置、測試、設定和部署作業。

在 Azure Synapse Analytics 工作區中,CI/CD 會將某個環境 (開發、測試、生產) 的所有實體移至另一個環境。 將您的工作區升階至另一個工作區的程序分為兩個部分。 首先,您要使用 Azure Resource Manager 範本 (ARM 範本) 來建立或更新工作區資源 (集區和工作區)。 然後,在 Azure DevOps 中或 GitHub 上使用 Synapse 工作區部署工具來移轉各種成品,例如 SQL 指令碼和筆記本、Spark 作業定義、管線、資料集和其他成品。

本文會概述如何使用 Azure DevOps 發行管線和 GitHub Actions,將 Azure Synapse 工作區自動部署到多個環境。

必要條件

若要將 Azure Synapse 工作區自動部署到多個環境,您必須先具備下列必要條件和設定。 您可以選擇使用 Azure DevOps GitHub,根據您的喜好設定或現有的設定。

Azure DevOps

如果您使用 Azure DevOps:

GitHub

如果您使用 GitHub:

  • 建立包含 Azure Synapse 工作區成品和工作區範本的 GitHub 存放庫。
  • 確定您已建立自我裝載的執行器,或使用 GitHub 裝載的執行器。

Microsoft Entra ID

  • 如果您是使用服務主體,請在 Microsoft Entra ID 中建立要用於部署的服務主體。
  • 如果您使用的是受控識別,請在 Azure 中的 VM 上啟用系統指派的受控識別來作為代理程式或執行器,然後以 Synapse 管理員的身分將其新增至 Azure Synapse Studio。
  • 使用 Microsoft Entra 系統管理員角色來完成這些動作。

Azure Synapse Analytics

注意

您可以使用相同的管線、ARM 範本或 Azure CLI 來自動執行和部署這些必要條件,但這些程序不在本文說明範圍內。

  • 您必須在 Azure Synapse Studio 中使用 Git 存放庫設定用於開發的「來源」工作區。 如需詳細資訊,請參閱 Azure Synapse Studio 中的原始檔控制

  • 設定空白工作區以作為部署目的地:

    1. 建立新的 Azure Synapse 工作區。
    2. 將新 Synapse 工作區的下列權限授與服務主體:
      • Microsoft.Synapse/workspaces/integrationruntimes/write
      • Microsoft.Synapse/workspaces/operationResults/read
      • Microsoft.Synapse/workspaces/read
    3. 在此工作區中,請勿設定 Git 存放庫連線。
    4. 在 Azure Synapse 工作區中,移至 [工作室]>[管理]>[存取控制]。 將「Synapse 成品發行者」指派給服務主體。 如果部署管線需要部署受控私人端點,請改為指派「Synapse 系統管理員」。
    5. 當您使用連線資訊儲存在 Azure 金鑰保存庫 的連結服務時,建議針對不同的環境保留個別的密鑰保存庫。 您也可以針對每個金鑰保存庫設定個別的權限等級。 例如,您可能不希望小組成員擁有生產秘密的權限。 如果您遵循此方法,建議您在所有階段中都保留相同的秘密名稱。 如果您保留相同的秘密名稱,就不需要跨 CI/CD 環境參數化每個連接字串,因為唯一變更的項目是金鑰保存庫名稱,也就是個別參數。

其他先決條件

  • 工作區部署工作不會建立 Spark 集區和自我裝載整合執行階段。 如果您的連結服務使用自我裝載整合執行階段,請在新工作區中手動建立執行階段。
  • 如果開發工作區中的項目連結了特定集區,請務必要在參數檔案中,為目標工作區中的集區建立相同名稱,或將名稱參數化。
  • 如果您佈建的 SQL 集區在您嘗試進行部署時遭到暫停,則部署可能會失敗。

如需詳細資訊,請參閱 Azure Synapse Analytics 中的 CI/CD 第 4 部分 - 發行管線

在 Azure DevOps 中設定發行管線

在本節中,您將了解如何在 Azure DevOps 中部署 Azure Synapse 工作區。

  1. Azure DevOps 中開啟您為發行建立的專案。

  2. 在左側功能表中,選取 [管線]>[發行]

    此螢幕擷取畫面顯示在 Azure DevOps 功能表上依序選取 [管線] 和 [發行]。

  3. 選取 [新增管線]。 如果您有現有管線,請選取 [新增]>[新增發行管線]

  4. 選取 [空白作業] 範本。

    此螢幕擷取畫面顯示選取空白作業範本。

  5. 在 [階段名稱] 中,輸入您的環境名稱。

  6. 選取 [新增成品],然後選取開發環境中使用 Azure Synapse Studio 所設定的 Git 存放庫。 選取您用來管理集區和工作區 ARM 範本的 Git 存放庫。 如果您使用 GitHub 作為來源,請為 GitHub 帳戶和提取存放庫建立服務連線。 如需詳細資訊,請參閱服務連線

    此螢幕擷取畫面顯示選取 GitHub,為新成品新增發佈分支。

  7. 選取資源 ARM 範本分支。 針對 [預設版本],選取 [預設分支中的最新版本]

    此螢幕擷取畫面顯示設定資源 ARM 範本分支。

  8. 針對成品 [預設分支],選取存放庫 發佈分支 或其他包含 Synapse 成品的非發佈分支。 根據預設,發佈分支是 workspace_publish。 針對 [預設版本],選取 [預設分支中的最新版本]

    此螢幕擷取畫面顯示設定成品分。

為 ARM 範本設定階段工作以便建立和更新資源

如果您有可部署資源 (例如 Azure Synapse 工作區、Spark 和 SQL 集區或金鑰保存庫) 的 ARM 範本,請新增 Azure Resource Manager 部署工作來建立或更新這些資源:

  1. 在暫存檢視中,選取 [檢視暫存工作]

    此螢幕擷取畫面顯示設定階段檢視。

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

  3. 在部署的 [工作] 索引標籤中,為工作區選取訂用帳戶、資源群組和位置。 視需要提供認證。

  4. 針對 [動作],選取 [建立或更新資源群組]

  5. 針對 [範本],選取省略符號按鈕 ()。 移至工作區的 ARM 範本。

  6. 針對 [範本參數],選取 […] 以選擇參數檔案。

    此螢幕擷取畫面顯示工作區和集區部署。

  7. 針對 [覆寫範本參數],選取 [...],然後輸入您想要讓工作區使用的參數值。

  8. 針對 [部署模式],選取 [增量]

  9. (選擇性) 新增用於授與的 Azure PowerShell,並更新工作區角色指派。 如果您使用發行管線來建立 Azure Synapse 工作區,則系統會將管線的服務主體新增為預設的工作區管理員。您可以執行 PowerShell,將工作區的存取權授與其他帳戶。

    此螢幕擷取畫面示範如何執行 PowerShell 指令碼以授與權限。

警告

在完整部署模式中,系統會刪除新的 ARM 範本中未指定的資源群組內的資源。 如需詳細資訊,請參閱 Azure Resource Manager 部署模式

設定階段工作以部署 Azure Synapse 成品

使用 Synapse 工作區部署擴充功能可在 Azure Synapse 工作區中部署其他項目。 您可以部署的項目包括資料集、SQL 指令碼和筆記本、Spark 作業定義、整合執行階段、資料流程、認證,以及工作區中的其他成品。

安裝及新增部署延伸模組

  1. 請透過 Visual Studio Marketplace 來搜尋並取得擴充功能。

    此螢幕擷取畫面顯示在 Visual Studio Marketplace 中的 Synapse 工作區部署延伸模組。

  2. 選取要在其中安裝擴充功能的 Azure DevOps 組織。

    此螢幕擷取畫面顯示選取要安裝 Synapse 工作區部署延伸模的組織。

  3. 確定已向 Azure DevOps 管線的服務主體授與訂用帳戶權限,並將該服務主體指派為工作區的 Synapse 工作區管理員。

  4. 若要建立新工作,請搜尋 Synapse 工作區部署,然後選取 [新增]

    此螢幕擷取畫面顯示搜尋 Synapse 工作區部署以建立工。

設定部署工作

部署工作支援三種類型的作業,只驗證、部署和驗證和部署。

注意

其中的這個工作區部署延伸模組無法向後相容。 請確定已安裝並使用最新版本。 您可以閱讀 Azure DevOps 中概覽的版本資訊,以及 GitHub 動作中的最新版本

驗證 是使用工作驗證非發佈分支中的 Synapse 成品,併產生工作區範本和參數範本檔案。 驗證作業僅適用於 YAML 管線。 以下是 YAML 檔案範例:

   pool:
     vmImage: ubuntu-latest

   resources:
     repositories:
     - repository: <repository name>
       type: git
       name: <name>
       ref: <user/collaboration branch>

   steps:
     - checkout: <name>
     - task: Synapse workspace deployment@2
       continueOnError: true    
       inputs:
         operation: 'validate'
         ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
         TargetWorkspaceName: '<target workspace name>'    

驗證和部署 可用來使用成品根資料夾,直接從非發佈分支部署工作區。

注意

當選取的作業類型為 [驗證] 或 [驗證並部署] 時,部署工作必須從此端點 web.azuresynapse.net 下載相依性 JS 檔案。 如果已在 VM 上啟用網路原則,請確定允許端點 web.azuresynapse.net

驗證並部署作業可在傳統和 YAML 管線中執行。 以下是 YAML 檔案範例:

   pool:
     vmImage: ubuntu-latest

   resources:
     repositories:
     - repository: <repository name>
       type: git
       name: <name>
       ref: <user/collaboration branch>

   steps:
     - checkout: <name>
     - task: Synapse workspace deployment@2
       continueOnError: true    
       inputs:
         operation: 'validateDeploy'
         ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
         TargetWorkspaceName: 'target workspace name'
         azureSubscription: 'target Azure resource manager connection name'
         ResourceGroupName: 'target workspace resource group'
         DeleteArtifactsNotInTemplate: true
         OverrideArmParameters: >
           -key1 value1
           -key2 value2

部署 作業部署的輸入包括 Synapse 工作區範本和參數範本,可以在於工作區發佈分支中發佈之後或在驗證之後建立。 它與 1.x 版相同。

您可以根據使用案例選擇作業類型。 下列部分是部署的範例。

  1. 在工作中,選取 [部署] 作為作業類型。

    此螢幕擷取畫面顯示作業部署的選取項目。

  2. 在工作中,選取 [範本] 旁邊的 […],以選擇範本檔案。

  3. 選取 [範本參數] 旁邊的 […] 以選擇參數檔案。

  4. 選取工作區的連線、資源群組和名稱。

  5. 選取 [覆寫範本參數] 旁邊的 […]。 輸入您想要讓工作區使用的參數值,包括連結服務中使用的連接字串和帳戶金鑰。 如需詳細資訊,請參閱 Azure Synapse Analytics 中的 CI/CD

    此螢幕擷取畫面顯示在工作區中設定 Synapse 部署工作。

  6. 2.x 版僅支援受控私人端點的部署。請確定您選取正確的版本,並檢查 在範本中部署受控私人端點。

    此螢幕擷取畫面顯示選取 2.x 版以使用 synapse 部署工作部署私人端點。

  7. 若要管理觸發程序,您可以使用觸發程序切換來停止觸發程序,然後再部署。 您也可以新增工作,以在部署工作之後重新啟動觸發程序。

    此螢幕擷取畫面顯示在部署前後管理觸發程序。

重要

在 CI/CD 案例中,不同環境中的整合執行階段類型必須相同。 例如,如果您在開發環境中有自我裝載整合執行階段,則相同的整合執行階段也必須自我裝載在其他環境 (例如測試和生產環境) 中。 同樣地,如果您要跨多個階段共用整合執行階段,則整合執行階段必須連結起來,並自我裝載到所有環境中,例如開發、測試和生產環境。

建立用於部署的發行

在儲存所有變更之後,可選取 [建立發行] 以便手動建立發行。 若要了解如何自動建立發行,請參閱 Azure DevOps 發行觸發程序

此螢幕擷取畫面顯示 [新增發行管線] 窗格,其中醒目提示 [建立發行]。

在 GitHub Actions 中設定發行

在本節中,您將了解如何使用 GitHub Actions 來建立 GitHub 工作流程以便部署 Azure Synapse 工作區。

您可以使用 Azure Resource Manager 範本的 GitHub Actions,自動將工作區和計算集區的 ARM 範本部署至 Azure。

工作流程檔案

在存放庫 /.github/workflows/ 路徑的 YAML (.yml) 檔案中定義 GitHub Actions 工作流程。 此定義包含組成工作流程的各種步驟與參數。

.yml 檔案內有兩個區段:

區段​​ 工作
驗證 1.定義服務主體。
2. 建立 GitHub 秘密。
部署 部署工作區成品。

設定 GitHub Actions 秘密

GitHub Actions 秘密是已加密的環境變數。 只要是具有此存放庫共同作業者權限的人,都可以使用這些秘密來與存放庫中的 Actions 互動。

  1. 在 GitHub 存放庫中,選取 [設定] 索引標籤,然後選取 [秘密]>[新增存放庫秘密]

    此螢幕擷取畫面顯示選取 GitHub 元素以建立新的存放庫祕密。

  2. 為用戶端識別碼新增祕密,如果您使用服務主體來進行部署,則請新增用戶端密碼。 您也可以選擇將訂用帳戶識別碼和租用戶識別碼儲存為秘密。

新增您的工作流程

在 GitHub 存放庫中,移至 [動作]

  1. 選取 [自行設定工作流程]。

  2. 在工作流程檔案中,刪除 on: 區段之後的所有內容。 例如,剩餘的工作流程看起來可能會像下面範例:

    name: CI
    
    on:
    push:
        branches: [ master ]
    pull_request:
        branches: [ master ]
    
  3. 為工作流程重新命名。 在 [Marketplace] 索引標籤上搜尋 Synapse 工作區部署動作,然後新增動作。

    此螢幕擷取畫面顯示在 [Marketplace] 索引標籤上搜尋 Synapse 工作區部署工作。

  4. 設定必要值和工作區範本:

    name: workspace deployment
    
    on:
        push:
            branches: [ publish_branch ]
    jobs:
        release:
            # You also can use the self-hosted runners.
            runs-on: windows-latest
            steps:
            # Checks out your repository under $GITHUB_WORKSPACE, so your job can access it.
            - uses: actions/checkout@v2
            - uses: azure/synapse-workspace-deployment@release-1.0
            with:
              TargetWorkspaceName: 'target workspace name'
              TemplateFile: './path of the TemplateForWorkspace.json'
              ParametersFile: './path of the TemplateParametersForWorkspace.json'
              OverrideArmParameters: './path of the parameters.yaml'
              environment: 'Azure Public'
              resourceGroup: 'target workspace resource group'
              clientId: ${{secrets.CLIENTID}}
              clientSecret:  ${{secrets.CLIENTSECRET}}
              subscriptionId: 'subscriptionId of the target workspace'
              tenantId: 'tenantId'
              DeleteArtifactsNotInTemplate: 'true'
              managedIdentity: 'False'
    
  5. 您已準備好認可變更。 選取 [開始認可]、輸入標題,然後新增描述 (選擇性)。 然後,選取 [認可新檔案]

    此螢幕擷取畫面顯示在 GitHub 中認可工作流程。

    檔案會出現在存放庫的 .github/workflows 資料夾中。

    注意

    受控識別僅支援用於 Azure 中的自我裝載 VM。 請務必將執行器設定為自我裝載。 為 VM 啟用系統指派的受控識別,並將其新增至 Azure Synapse Studio 來作為 Synapse 管理員。

檢閱您的部署

  1. 在 GitHub 存放庫中,移至 [動作]

  2. 若要查看工作流程的執行詳細記錄,請開啟第一個結果:

    顯示選取工作區部署登入 GitHub 中存放庫 Actions 的螢幕快照。

在工作區範本中建立自訂參數

如果您使用自動化 CI/CD,並且想要在部署期間變更某些屬性,但系統預設不會將這些屬性參數化,則可以覆寫預設參數範本。

若要覆寫預設參數範本,請在 Git 分支的根資料夾中,建立名為 template-parameters-definition.json 的自訂參數範本。 您必須使用這個確切的檔案名稱。 當 Azure Synapse 工作區從協作分支發佈,或部署工作驗證其他分支中的成品時,工作區便會讀取此檔案,並使用其中設定來產生參數。 如果 Azure Synapse 工作區找不到該檔案,則會使用預設的參數範本。

自訂參數語法

您可以使用下列指導方針來建立自訂參數檔案:

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

參數範本定義的範例

以下是參數範本定義的內容範例:

{
    "Microsoft.Synapse/workspaces/notebooks": {
        "properties": {
            "bigDataPool": {
                "referenceName": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/sqlscripts": {
        "properties": {
            "content": {
                "currentConnection": {
                    "*": "-"
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/pipelines": {
        "properties": {
            "activities": [{
                "typeProperties": {
                    "waitTimeInSeconds": "-::int",
                    "headers": "=::object",
                    "activities": [
                        {
                            "typeProperties": {
                                "url": "-:-webUrl:string"
                            }
                        }
                    ]
                }
            }]
        }
    },
    "Microsoft.Synapse/workspaces/integrationRuntimes": {
        "properties": {
            "typeProperties": {
                "*": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/triggers": {
        "properties": {
            "typeProperties": {
                "recurrence": {
                    "*": "=",
                    "interval": "=:triggerSuffix:int",
                    "frequency": "=:-freq"
                },
                "maxConcurrency": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/linkedServices": {
        "*": {
            "properties": {
                "typeProperties": {
                    "accountName": "=",
                    "username": "=",
                    "connectionString": "|:-connectionString:secureString",
                    "secretAccessKey": "|"
                }
            }
        },
        "AzureDataLakeStore": {
            "properties": {
                "typeProperties": {
                    "dataLakeStoreUri": "="
                }
            }
        },
        "AzureKeyVault": {
            "properties": {
                "typeProperties": {
                    "baseUrl": "|:baseUrl:secureString"
                },
                "parameters": {
                    "KeyVaultURL": {
                        "type": "=",
                        "defaultValue": "|:defaultValue:secureString"
                    }
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/datasets": {
        "*": {
            "properties": {
                "typeProperties": {
                    "folderPath": "=",
                    "fileName": "="
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/credentials" : {
        "properties": {
            "typeProperties": {
                "resourceId": "="
            }
        }
    }
}

以下會依資源類型來說明如何建構前述範本。

notebooks

  • properties/bigDataPool/referenceName 路徑中的任何屬性都會使用其預設值進行參數化。 您可以針對每個筆記本檔案將連結的 Spark 集區參數化。

sqlscripts

  • properties/content/currentConnection 路徑中,poolNamedatabaseName 屬性都會參數化為字串,但不會使用範本中的預設值。

pipelines

  • activities/typeProperties/waitTimeInSeconds 路徑中的任何屬性都會參數化。 管線中具有名為 waitTimeInSeconds 之程式碼層級屬性的任何活動 (例如,Wait 活動) 都會參數化為數字,並採用預設名稱。 此屬性在 Resource Manager 範本中沒有預設值。 相反地,在 Resource Manager 部署期間,必須要輸入此屬性。
  • headers 屬性 (例如,在 Web 活動中) 會使用 object 類型 (物件) 進行參數化。 headers 屬性具有預設值,且此值與來源處理站的值相同。

integrationRuntimes

  • typeProperties 路徑中的所有屬性都會使用其各自的預設值進行參數化。 例如,有兩個屬性位於 IntegrationRuntimes 類型屬性底下:computePropertiesssisProperties。 這兩個屬性類型都是使用其各自的預設值和類型 (物件) 來建立。

triggers

  • typeProperties 底下,有兩個屬性會參數化:

    • maxConcurrency 屬性具有預設值,而且是 string 類型。 maxConcurrency 屬性的預設參數名稱是 <entityName>_properties_typeProperties_maxConcurrency
    • recurrence 屬性也已參數化。 recurrence 屬性底下的所有屬性都會設定為要使用預設值和參數名稱來參數化為字串。 例外狀況是 interval 屬性,其會參數化為 int 類型。 參數名稱後面會加上 <entityName>_properties_typeProperties_recurrence_triggerSuffix。 同樣地,freq 屬性是字串並已參數化為字串。 不過,freq 屬性已參數化但沒有預設值。 此名稱會縮短並加上尾碼,例如 <entityName>_freq

    注意

    目前最多支援 50 個觸發程序。

linkedServices

  • 連結服務是唯一的。 因為連結服務和資料集的類型廣泛,所以您可提供特定類型的自訂。 在上述範例中,系統會針對 AzureDataLakeStore 類型的所有連結服務套用特定範本。 針對所有其他範本(使用 * 字元識別),會套用不同的範本。
  • connectionString 屬性會參數化為 securestring 值。 其不會有預設值。 參數名稱會縮短並加上 connectionString 尾碼。
  • secretAccessKey 屬性會參數化為 AzureKeyVaultSecret 值 (例如,在 Amazon S3 連結服務中)。 此屬性會自動參數化為 Azure Key Vault 秘密,並從已設定的金鑰保存庫提取。 您也可以將金鑰保存庫本身參數化。

datasets

  • 雖然您可以在資料集內自訂類型,但不需要明確的 *-level 設定。 在上述範例中,typeProperties 下的所有資料集屬性都已參數化。

CI/CD 的最佳做法

如果您要搭配 Azure Synapse 工作區來使用 Git 整合,而且您有 CI/CD 管線可將開發環境中所做的變更先後移到測試環境和生產環境,則建議您採用以下最佳做法:

  • 只整合開發工作區與 Git。 如果您使用 Git 整合,請只整合您的開發 Azure Synapse 工作區與 Git。 測試和生產工作區中所進行的變更會透過 CI/CD 部署,不需要用到 Git 整合。
  • 先準備集區再遷移成品。 如果您在開發工作區中有連結到集區的 SQL 指令碼或筆記本,請在不同環境中使用相同的集區名稱。
  • 在基礎結構即程式碼案例中同步處理版本設定。 若要管理描述性模型中的基礎結構 (網路、虛擬機器、負載平衡器和連線拓撲),請使用 DevOps 小組用於原始程式碼的相同版本設定。
  • 檢閱 Azure Data Factory 最佳做法。 如果您使用 Data Factory,請參閱 Data Factory 成品的最佳做法

針對成品部署進行疑難排解

使用 Synapse 工作區部署工作來部署 Synapse 成品

不同於 Data Factory,Azure Synapse 中的成品不是 Resource Manager 資源。 您無法使用 ARM 範本部署工作來部署 Azure Synapse 成品。 請改用 Synapse 工作區部署工作來部署成品,並使用 ARM 資源的 ARM 部署工作 (集區和工作區) 部署。 同時,這項工作只支援資源類型為 Microsoft.Synapse 的 Synapse 範本。 透過這項工作,使用者可以自動從任何分支部署變更,而不需在 Synapse Studio 中手動按一下發行。 下列是一些經常引發的問題。

1.發佈失敗:工作區 arm 檔案超過 20 MB

Git 提供者中有檔案大小限制,例如,在 Azure DevOps 中,檔案大小上限為 20 Mb。 一旦工作區範本檔案大小超過 20 Mb,當您在 Synapse Studio 中發佈變更時,就會發生此錯誤,其中產生工作區範本檔案並同步至 git。 若要解決此問題,您可以使用 Synapse 部署工作來驗證驗證和部署作業,直接將工作區範本檔案儲存到管線代理程式,而不需在 synapse Studio 中手動發佈。

2.發行中的未預期權杖錯誤

如果您的參數檔案有未逸出的參數值,發行管線會無法剖析該檔案,並且會產生 unexpected token 錯誤。 建議您覆寫參數,或使用 Key Vault 來擷取參數值。 您也可以使用雙逸出字元來解決此問題。

3.整合執行階段部署失敗

如果您已從已啟用受控虛擬網路的工作區產生工作區範本,並嘗試部署至一般工作區,反之亦然,就會發生此錯誤。

4.剖析值時遇到非預期的字元

無法剖析範本檔案。 嘗試逸出反斜線,例如 \\Test01\Test

5.無法擷取工作區資訊,找不到

目標工作區資訊未正確設定。 請確定您已建立的服務連線範圍設定為具有工作區的資源群組。

6.成品刪除失敗

延伸模組會比較發行分支中存在的成品與範本,並根據差異來刪除成品。 請確定您未嘗試刪除任何存在於發佈分支中的成品,而其他成品有參考或相依性。

7. 部署失敗,發生錯誤:json 位置 0

如果您嘗試手動更新範本,就會發生此錯誤。 請確定您尚未手動編輯範本。

8. 檔案建立或更新失敗,因為參考無效

synapse 中的成品可由另一個成品參考。 如果您已將成品中所參考的屬性參數化,請務必為它提供正確和非 Null 值

9.無法在筆記本部署中擷取部署狀態

您嘗試部署的筆記本會附加至工作區範本檔案中的 Spark 集區,而在部署中,集區不存在於目標工作區中。 如果您未參數化集區名稱,請確定在環境之間具有相同名稱的集區。