了解端對端部署
Pipelines 是彈性的工具，您可以透過許多不同的方式進行設定來符合您的需求。 在本單元中，您會了解如何使用管線來部署整個解決方案，包括設定 Azure 基礎結構，以及如何執行其他部署作業。
有多少管線？
在某些組織中，管理 Azure 環境的小組與開發環境中所執行程式碼的小組不同。 在這些情況下，通常想要建立多個管線，且每個管線都是由負責其特定區域的小組所擁有。 例如，您可以建立一個管線來部署 Bicep 程式碼 (可部署網站 Azure 資源)，以及另一個管線來部署網站應用程式。
雖然這種方法能讓您在管理管線的方式上有一些彈性，但要讓所有項目保持同步可能會很困難。例如，假設您的網站小組在其 Azure App Service 應用程式上需要新的設定，以啟用其所建置的功能。 在基礎結構部署管線成功完成之前，應用程式部署管線都無法執行。 此外，在管線之間傳送資料 (例如基礎結構管線所建立 Azure 資源的名稱) 可能會變得很複雜。
相反地，最好建立單一管線來部署解決方案所需的所有項目，即使元件是由不同人員或不同小組所管理也一樣。 您可以使用 Git 和 Azure DevOps 之類的工具來協調您的工作。 您在新增新功能時，可以使用分支對 Bicep 檔案進行必要的變更。 當變更準備好進行整合及發行時，單一管線會執行建置和部署解決方案的所有必要步驟。 單一管線可減少項目發生不同步的機會。
提示
當您為解決方案建置程式碼時，可能需要經常部署該程式碼，以便測試其運作方式。 您可能會發現，將基礎結構與應用程式程式碼一起部署時，會使您的管線執行速度變慢，並禁止您的進度。
如果您處於這個情況，則可以考慮停用開發環境的基礎結構部署。 您可以使用路徑篩選、管線範本和條件來達成此目的。 不過，您應該讓其他環境的完整部署順序保持不變。
控制平面和資料平面
許多 Azure 資源都會提供兩個不同的平面可供存取。 控制平面會部署並設定資源。 資料平面可讓您存取資源的功能。
當您建立和部署 Bicep 檔案時，會與控制平面進行互動。 在 Azure 中，控制平面是 Azure Resource Manager。 您可以使用 Resource Manager 來定義每個資源的設定。
但您的管線通常不只需要與控制平面進行互動。 例如，您可能需要執行其他工作：
- 將 Blob 上傳至儲存體帳戶。
- 修改資料庫結構描述。
- 對協力廠商服務進行 API 呼叫。
- 觸發機器學習模型的更新。
- 將網站部署至 Azure App Service 應用程式。
- 將軟體部署至虛擬機器。
- 向協力廠商提供者註冊網域名稱伺服器 (DNS) 項目。
當您考慮使用端對端管線時，通常需要部署 Azure 資源，然後針對這些資源的資料平面執行一系列作業。 有時候，這些作業會稱為部署的最後一哩路，因為您要使用控制平面來執行大部分的部署，而且只有少量設定會保留下來。
注意
有些資源的控制平面與資料平面之間並沒有清楚的劃分。 這些資源包括 Azure Data Factory 和 Azure API 管理。 這兩項服務都支援使用 Bicep 進行完全自動化的部署，但需要特殊考量。 您可以在課程模組結尾的 [摘要] 頁面上找到其他資訊的連結。
如何執行資料平面作業
當您建立的部署管線可與資源資料平面進行互動時，可以使用下列三種常見方法之一：
- Resource Manager 部署指令碼。
- 管線指令碼。
- 管線工作。
Resource Manager 部署指令碼是在 Bicep 檔案中進行定義。 其會執行 Bash 或 PowerShell 指令碼，並可與 Azure CLI 或 Azure PowerShell Cmdlet 互動。 您可以建立受控識別，使得部署指令碼可向 Azure 進行驗證，而 Azure 會自動佈建和管理執行部署指令碼所需的其他資源。
當您需要在部署程序內執行基本的指令碼時，就很適合使用部署指令碼。 不過，其並無法讓您輕鬆從管線存取其他元素。
您也可以從部署管線內執行自己的邏輯。 Azure Pipelines 會針對您需要執行的一般工作，提供豐富的工作生態系統。 如果您找不到符合您需求的工作，則可以使用指令碼來執行自己的 Bash 或 PowerShell 程式碼。 管線工作和指令碼是從管線的代理程式執行。 您通常需要向所使用服務的資料平面驗證工作或指令碼，而執行驗證的方式則取決於服務。
管線工作和指令碼可讓您獲得彈性並有所掌控。 其也可讓您存取管線成品，您很快就會了解這些成品。 在本課程模組中，我們著重於管線指令碼和工作。 在課程模組結尾的 [摘要] 頁面上，我們會連結至 Resource Manager 部署指令碼的詳細資訊。
輸出
管線通常會部署 Bicep 檔案，藉此建立及設定您的 Azure 資源。 接著，管線的後續部分會與這些資源的資料平面進行互動。 為了能夠與資源進行互動，管線工作和步驟需要您所建立 Azure 資源的相關資訊。
例如，假設您的 Bicep 模組部署了儲存體帳戶。 您需要管線部署儲存體帳戶，然後將某些 Blob 上傳至儲存體帳戶中的 Blob 容器。 上傳 Blob 的管線工作必須得知要連線目標儲存體帳戶的名稱，以及要上傳檔案的目標 Blob 容器名稱。
最好讓 Bicep 檔案來決定 Azure 資源的名稱。 其可能會使用參數、變數或運算式來建立儲存體帳戶和 Blob 容器的名稱。 然後，Bicep 檔案可以將提供每個資源名稱的輸出公開。 管線中的後續步驟可以讀取輸出的值。 如此一來，您的管線定義就不必將可能在環境之間變更的任何名稱或其他資訊進行硬式編碼。 此外，定義不需要以 Bicep 檔案中定義的規則為基礎。
您可以透過 Azure Pipelines，使用管線變數來傳播輸出的值。 您可以在管線指令碼中設定管線變數的值。 您可以使用 Azure Pipelines 了解如何解譯的特別格式化記錄輸出，如下所示：
stages:
- stage: Stage1
jobs:
- job: Job1
steps:
# Set the variable's value.
- script: |
echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
name: Step1
# Read the variable's value.
- script:
echo $(myVariableName)
當您在一個作業中建立變數，但想要在相同階段的另一個作業中存取它時，您需要對應它。
stages:
- stage: Stage2
jobs:
- job: Job2
steps:
# Set the variable's value.
- script: |
echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
name: Step1
- job: Job3
dependsOn: Job2
variables: # Map the variable to this job.
myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
steps:
# Read the variable's value.
- script: |
echo $(myVariableName)
若要跨管線階段存取變數，您也需要對應變數，但使用不同的語法：
stages:
- stage: Stage2
jobs:
- job: Job2
steps:
# Set the variable's value.
- script: |
echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
name: Step1
- job: Job3
dependsOn: Job2
variables: # Map the variable to this job.
myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
steps:
# Read the variable's value.
- script: |
echo $(myVariableName)
- stage: Stage3
dependsOn: Stage2
jobs:
- job: Job4
variables: # Map the variable to this stage.
myVariableName: $[ stageDependencies.Stage2.Job2.outputs['Step1.myVariableName'] ]
steps:
# Read the variable's value.
- script: |
echo $(myVariableName)
您可以使用 Bicep 輸出和管線變數，藉此建立多階段管線來部署 Bicep 程式碼，然後在部署期間對資源執行各種動作。