了解管線階段

  • 7 分鐘

管線可讓您自動執行部署程序中的步驟。 程序中可能包含數個您想要執行的作業邏輯群組。 在此單元中，您將了解工作管線階段，以及如何使用這些階段將品質控制程序新增至 Bicep 部署。

什麼是管線階段？

階段可協助您將管線分割成多個邏輯區塊。 每個階段可包含一或多個作業。 作業包含應完成之步驟的排序清單，例如執行命令列指令碼。

顯示包含一個作業之階段的管線圖表。作業包含四個步驟。

您可以在管線中使用階段來標示關注點分離。 例如，當您使用 Bicep 程式碼時，驗證程式碼與部署 Bicep 檔案是不同的考量。 當您使用自動化管線時，建置和測試程式碼通常稱為持續整合 (CI)。 在自動化管線中部署程式碼，通常稱為持續部署 (CD)。

在 CI 階段中，您會檢查對程式碼所做的變更是否有效。 CI 階段提供品質保證。 這些作業可以執行，而不會影響實際執行環境。

在許多程式設計語言中，必須先建置程式碼，才能加以執行。 Bicep 檔案在部署時，會從 Bicep 轉換為 JSON。 此工具會自動執行此程序。 在大部分情況下，您不需要手動將 Bicep 程式碼建置到管線內的 JSON 範本。 不過，當我們討論 Bicep 程式碼時，我們仍會使用「持續整合」一詞，因為 CI 的其他部分仍適用，例如驗證程式碼。

成功執行 CI 階段後，您應該會更加確信您所做的變更也會成功部署。 在 CD 階段中，您會將程式碼部署到每個環境。 您通常會從測試和其他非實際執行環境開始，然後再移至實際執行環境。 在此課程模組中，我們將部署至單一環境。 在未來的課程模組中，您將了解如何擴充部署管線，以部署到多個環境，例如非實際執行環境和實際執行環境。

階段會依序執行。 您可以控制每個階段的執行方式和時間。 例如，您可以設定 CD 階段，使其在 CI 階段成功執行後才會執行。 或者，您可能有多個 CI 階段需要依序執行，例如建置程式碼，然後加以測試。 您也可以包含只有在先前的部署階段失敗時才會執行的復原階段。

左移

藉由使用階段，您可以在部署程式碼之前驗證程式碼的品質。 這些階段有時會稱為左移。

請考量您在撰寫程式碼時所執行之活動的時間表。 時間表從規劃和設計階段開始。 然後移至組建和測試階段。 最後，您會部署且必須支援解決方案。

圖表的水平軸上為時間表、垂直軸上為成本，以及一條線，顯示成本會在後續發現錯誤時增加。

在軟體開發中，一個眾所皆知的規則是，您在程序越早發現錯誤 (越接近時間表左邊)，就能更容易、更快速、更便宜地修正錯誤。 您在程序中越晚發現錯誤，修正就更為困難。

因此，目標是將問題的探索往上圖的左側移動。 在本課程模組中，您將了解如何在管線進行時對其新增更多驗證和測試。

您甚至可以在部署開始之前先新增驗證。 當您使用 Azure DevOps 之類的工具時，提取要求通常會代表小組中的某人想要對主要分支上的程式碼所做的變更。 建立另一個管線，以在提取要求的檢閱程序期間自動執行 CI 步驟，會很有幫助。 這項技術有助於驗證即使發生建議的變更，程式碼是否仍可運作。 如果驗證成功，您就確信變更不會在合併至主要分支時造成問題。 如果檢查失敗，您就知道提取要求準備好要合併之前還有更多工作要做。

重要

自動化驗證和測試只會與您撰寫的測試一樣有效。 請務必考量您需要測試哪些項目，以及需要執行哪些步驟，以確保部署正常。

定義管線階段

每個管線都至少包含一個階段。 如果管線只有單一階段，則無須明確加以定義。 Azure Pipelines 會自動進行其定義。 在管線中有多個階段時，您必須定義每個階段。 階段會依照您指定的順序執行。

假設您建置了需要部署兩次的 Bicep 檔案：一次是在美國的基礎結構，一次是在歐洲的基礎結構。 部署之前，請先驗證 Bicep 程式碼。 以下圖例顯示定義此程序的多階段管線：

圖表顯示的管線具有驗證階段、部署美國階段和部署歐洲階段，三者依序執行。

請注意，此範例有三個階段。 驗證階段類似於 CI 階段。 然後，會執行 DeployUS 和 DeployEurope 階段。 每個階段分別會將程式碼部署至其中一個環境。

以下是在管線 YAML 檔案中定義階段的方式：

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

控制階段的順序

根據預設，階段會依照您定義的順序執行。 前一個階段成功後，才會執行後續階段。 您可以新增階段之間的相依性，以變更順序。

承上例，假設您想要以平行方式執行這兩個部署，如下所示：

圖表顯示的管線具有驗證階段、部署美國階段和部署歐洲階段，這兩個部署階段並行執行。

您可以使用 dependsOn 關鍵字來指定階段之間的相依性：

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

當您使用 dependsOn 關鍵字時，Azure Pipelines 會等到相依的階段順利完成後，才開始下一個階段。 如果 Azure Pipelines 偵測到多個階段的所有相依性皆已滿足，即可平行執行這些階段。

注意

事實上，只有在您有足夠的代理程式可同時執行多個作業時，階段和作業才會平行執行。 使用 Microsoft 裝載的代理程式時，您可能需要購買額外的平行作業才能達成此目的。

有時候，您會想要在上一個階段失敗時執行後續階段。 例如，以下是不同的管線。 如果部署失敗，隨後會立即執行名為復原的階段：

圖表顯示的管線具有一個部署階段及一個條件，使得部署階段中的失敗會導致復原階段執行。

您可以使用 condition 關鍵字，來指定階段執行之前應符合的條件：

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

在上述範例中，當一切順利時，Azure Pipelines 會先執行驗證階段，然後再執行部署階段。 它會略過復原階段。 不過，如果部署階段失敗，Azure Pipelines 就會執行復原階段。 您將在此課程模組的後續部分深入了解復原。

每個作業都會在新的代理程式上執行。 這表示每個作業都會從乾淨的環境開始，因此在每個作業中，作為第一個步驟，通常需要簽出原始程式碼。

Bicep 部署階段

一般的 Bicep 部署管線包含數個階段。 隨著管線執行各階段時，目標是要愈加確信後續的階段將會成功。 以下是 Bicep 部署管線的常見階段：

圖表顯示具有五個階段的 Bicep 部署管線：Lint、驗證、預覽、部署和煙霧測試。

  1. Lint：使用 Bicep Linter 來驗證 Bicep 檔案的格式正確，且不包含任何明顯的錯誤。
  2. 驗證：使用 Azure Resource Manager 預檢驗證程序來檢查在部署時可能發生的問題。
  3. 預覽：使用假設狀況命令來驗證將對 Azure 環境套用的變更清單。 要求人員手動檢閱假設狀況結果，並核准管線以繼續進行。
  4. 部署：將部署提交至 Resource Manager，並等候其完成。
  5. 煙霧測試：針對您已部署的一些重要資源執行基本部署後檢查。 我們將這些檢閱稱為基礎結構煙霧測試。

您的組織可能會有不同的階段順序，或者，您可能需要將 Bicep 部署整合到部署其他元件的管線中。 了解階段的運作方式之後，您就可以根據自身需求設計管線。

在此課程模組中，您將深入了解此處所列的階段，並逐漸建置包含各個階段的管線。 您也將了解：

  • 管線如何在任何先前的階段中發生非預期的情況時停止部署程序。
  • 如何將管線設定為暫停，直到您手動確認上一個階段發生什麼情況為止。