新增階段、相依性和條件

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

階段是 Azure DevOps 管線中的邏輯界限。 階段可用來將軟體開發程式中的動作分組（例如，建置應用程式、執行測試、部署至生產階段）。 每個階段都包含了一或多個作業。

當您在管線中定義多個階段時，預設情況下，它們會一個接一個地執行。 階段也可以彼此相依。 您可以使用 dependsOn 關鍵詞來定義 相依性。 階段也可以根據具有條件的上一個階段的結果來執行。

若要了解階段如何使用平行作業和授權，請參閱 設定和支付平行作業的費用。

若要了解階段與管線的其他部分的關係，例如作業，請參閱 重要管線概念。

您也可以深入了解階段與 YAML 架構階段一文中管線部分的關聯程度。

YAML

您可以將管線作業組織成階段。 階段是管線中的主要部門：建置此應用程式、執行這些測試，以及部署到生產階段是良好的階段範例。 它們是管線中的邏輯界限，您可以在其中暫停管線並執行各種檢查。

即使您未明確定義管線，每個管線至少有一個階段。 您也可以將階段排列成相依性圖形，讓一個階段在另一個階段之前執行。 階段的作業限制為256個。

傳統

將發行管線中的部署作業組織成階段。 階段是發行管線的主要部門：執行功能測試、部署至生產階段，以及部署到生產階段是良好的發行階段範例。

發行管線中的階段包含作業和工作。

核准和閘道、部署條件和觸發程式，以及在發行部署到階段時控制佇列原則。

指定階段

YAML

在最簡單的情況下，您不需要管線中的任何邏輯界限。 在此情況下，您不需要明確使用 stage 關鍵詞。 您可以直接在 YAML 檔案中指定作業。

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

如果您將管線組織成多個階段，請使用 stages 關鍵詞。

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

如果您選擇在階段層級指定 pool ，除非在作業層級指定，否則在該階段中定義的所有作業都會使用該集區。

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

指定階段的完整語法為：

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

傳統

若要將階段新增至發行管線，請在 [發行] 頁面中選取發行管線，選取要編輯的動作，然後選取 [管線] 索引卷標。雖然定義階段最重要的部分是自動化工作，但您也可以為發行管線中的階段設定數個屬性和選項。 您可以：

• 視需要在這裡編輯階段的名稱。
• 將一個使用者或群組指定為階段擁有者。 每當部署至該階段失敗時，階段擁有者就會收到通知。 作為階段擁有者不會自動隨附任何許可權。
• 從管線中刪除階段。
• 變更階段的順序。
• 將階段的複本儲存為 階段範本。
• 管理階段的安全性設定。

指定相依性

YAML

在管線中定義多個階段時，預設會依您在 YAML 檔案中定義的順序循序執行。 不過新增相依性時，就會出現例外狀況。 使用相依性時，階段會依 dependsOn 需求的順序執行。

管線至少必須包含一個沒有相依性的階段。

定義多個階段及其相依性的語法如下：

stages:
- stage: string
  dependsOn: string
  condition: string

循序執行的範例階段：

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

平行執行的範例階段：

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

展開扇出和風扇的範例：

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    # this stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # this stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # this stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

傳統

您可以在發行管線的每個階段設定觸發程式來控制相依性：

• 階段會以觸發程式或手動啟動來執行。
• 使用 「發行後」觸發程式時，發行開始時，階段就會啟動，並與其他具有發行後觸發程式的階段平行。
• 使用 After 階段觸發程式時，所有相依階段完成之後就會開始階段。 使用此方式，您可以針對階段建立展開和扇入行為的模型。

定義條件

您可以指定每個階段使用 表示式執行的條件。 根據預設，如果階段不相依於任何其他階段，或相依的所有階段都已完成且成功，則會執行階段。 您可以強制階段執行此行為，即使先前階段失敗或指定自定義條件也一樣。

如果您針對階段自定義上述步驟的默認條件，您可以移除完成和成功的條件。 因此，如果您使用自定義條件，通常會使用 and(succeeded(),custom_condition) 來檢查上一個階段是否成功執行。 否則，不論上一個階段的結果為何，階段都會執行。

注意

失敗的條件 （'JOBNAME/STAGENAME'） 和成功 #'JOBNAME/STAGENAME'），如下列範例 僅適用於 YAML 管線。

YAML

根據執行上一個階段狀態執行階段的範例：

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

使用 自訂條件的範例：

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

傳統

當您指定 [發行后] 或 [在階段 之後] 觸發程式時，您也可以指定發行中所取用成品的分支篩選。 只有在滿足分支篩選條件時，版本才會部署到階段。

指定佇列原則

YAML

YAML 管線不支援佇列原則。 管線的每個執行都與其他執行無關，而且不知道其他執行。 換句話說，您的兩個連續認可可能會觸發兩個管線，而且兩者都會執行相同的階段順序，而不會彼此等候。 雖然我們努力將佇列原則帶入 YAML 管線，但建議您使用 手動核准 ，以便在這很重要時手動排序並控制執行順序。

傳統

在某些情況下，您可能能夠產生比部署的組建更快。 或者，您可以設定多個 代理程式 ，例如，從相同的發行管線建立發行，以部署不同的成品。 在這種情況下，能夠控制多個發行排入階段的方式很有用。 佇列原則 可讓您控制該控件。

您可以為佇列原則選擇的選項如下：

• 平行部署數目：如果您在階段中動態布建新資源，且實際能夠平行處理多個版本的部署，但您想要限制平行部署的數目，請使用此選項。

• 如果您指定部署數目上限，則會再顯示兩個選項：

  • 依序部署：如果您想要依序將所有版本部署至相同的共用實體資源，請使用此選項。 藉由接著部署組建，您可以一個接一個地確保兩個部署作業不會同時以相同的實體資源為目標，即使有多個可用的組建和發行代理程式也一樣。 您也會確保階段的預先部署核准要求會依序傳送。

  • 部署最新並取消其他組建：如果您要產生比發行快的組建，而且只想要部署最新的組建，請使用此選項。

若要了解這些選項的運作方式，請考慮在快速連續建立單一發行管線的 R1、R2...、R5 發行案例。 假設此管線中的第一個階段名為 QA ，且已定義預先部署和部署後核准者。

• 如果您未指定平行部署數目的限制，所有五個核准要求都會在發行建立后立即傳送。 如果核准者核准所有版本，它們全都會平行部署到 QA 階段。 （如果 QA 階段未定義任何預先部署核准者，所有五個版本都會以平行方式部署到此階段。

• 如果您指定限制並 依序部署所有，且已達到限制，則會先傳送發行 R1 的預先部署核准。 完成此核准之後，即會開始將發行 R1部署到 QA 階段。 接下來，會針對發行 R1 傳送部署後核准的要求。 只有在完成此部署后核准之後，才會開始執行發行 R2 ，併發出其預先部署核准。程式會接著針對所有版本繼續執行此程式。

• 如果您指定限制並部署最新並取消其他限制，且已達到限制，則會略過發行 R2、R3 和 R4，且 QA 階段中 R5 的預先部署核准會在發行 R1 完成部署後核准後立即傳送。

指定核准

YAML

您可以使用核准檢查手動控制階段何時應該執行。 這通常用來控制生產環境的部署。 檢查是可供資源擁有者用來控制管線中階段是否可以取用資源的機制。 身為資源的擁有者，例如環境，您可以定義在取用該資源的階段之前必須滿足的檢查。

目前，環境支援手動核准檢查。 如需詳細資訊，請參閱 核准。

傳統

您可以在管線中每個階段的開頭或結尾新增手動核准。 如需詳細資訊，請參閱 發行核准和閘道概觀。