ステージ、依存関係、条件を追加する

パイプライン ジョブをステージに分けて整理できます。 ステージはパイプラインの主要な部分であり、このアプリの構築、これらのテストの実行、実稼働前のデプロイは、ステージの適切な例です。 これらはパイプライン内の論理境界であり、パイプラインを一時停止してさまざまなチェックを実行できます。

明示的に定義しない場合でも、すべてのパイプラインには少なくとも 1 つのステージがあります。 ステージを依存関係グラフに配置して、あるステージが別のステージの前に実行されるようにすることもできます。 ステージには、最大 256 個のジョブを含めることができます。

最も単純なケースでは、パイプラインに論理境界は必要ありません。 このようなシナリオでは、 stages キーワードを使用せずに、YAML ファイル内のジョブを直接指定できます。 たとえば、個別の環境やデプロイ手順を必要とせずに小規模なアプリケーションをビルドしてテストする単純なパイプラインがある場合は、ステージを使用せずにすべてのジョブを直接定義できます。

pool:
  vmImage: 'ubuntu-latest'

jobs:
- job: BuildAndTest
  steps:
  - script: echo "Building the application"
  - script: echo "Running tests"

このパイプラインには、1 つの暗黙的なステージと 2 つのジョブがあります。 ステージが 1 つしかないため、 stages キーワードは使用されません。

jobs:
- job: Build
  steps:
  - bash: echo "Building"

- job: Test
  steps:
  - bash: echo "Testing"

パイプラインを複数のステージに整理するには、 stages キーワードを使用します。 この YAML は、各ステージに複数のジョブが含まれており、各ジョブに実行する特定のステップがある 2 つのステージを含むパイプラインを定義します。

stages:
- stage: A
  displayName: "Stage A - Build and Test"
  jobs:
  - job: A1
    displayName: "Job A1 - build"
    steps:
    - script: echo "Building the application in Job A1"
      displayName: "Build step"
  - job: A2
    displayName: "Job A2 - Test"
    steps:
    - script: echo "Running tests in Job A2"
      displayName: "Test step"

- stage: B
  displayName: "Stage B - Deploy"
  jobs:
  - job: B1
    displayName: "Job B1 - Deploy to Staging"
    steps:
    - script: echo "Deploying to staging in Job B1"
      displayName: "Staging deployment step"
  - job: B2
    displayName: "Job B2 - Deploy to Production"
    steps:
    - script: echo "Deploying to production in Job B2"
      displayName: "Production deployment step"

ステージ レベルで 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

パイプラインで複数のステージを定義する場合、YAML ファイルで定義した順序で、既定で順番に実行されます。 ここでの例外は、依存関係を追加する場合です。 依存関係を使用すると、ステージは、dependsOn 要件の順序で実行されます。

パイプラインには、依存関係のないステージが少なくとも 1 つ含まれている必要があります。

ステージを定義する方法の詳細については、 YAML スキーマのステージを参照してください。

次のステージ例は、順番に実行されます。 dependsOn キーワードを使用しない場合、ステージは定義された順序で実行されます。

stages:
- stage: Build
  displayName: "Build Stage"
  jobs:
  - job: BuildJob
    steps:
    - script: echo "Building the application"
      displayName: "Build Step"

- stage: Test
  displayName: "Test Stage"
  jobs:
  - job: TestJob
    steps:
    - script: echo "Running tests"
      displayName: "Test Step"

並列で実行されるステージの例:

stages:
- stage: FunctionalTest
  displayName: "Functional Test Stage"
  jobs:
  - job: FunctionalTestJob
    steps:
    - script: echo "Running functional tests"
      displayName: "Run Functional Tests"

- stage: AcceptanceTest
  displayName: "Acceptance Test Stage"
  dependsOn: [] # Runs in parallel with FunctionalTest
  jobs:
  - job: AcceptanceTestJob
    steps:
    - script: echo "Running acceptance tests"
      displayName: "Run Acceptance Tests"

ファンアウト動作とファンイン動作の例:

stages:
- stage: Test

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

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

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

前のステージの実行状態に基づいてステージを実行する例:

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 パイプラインでは、キュー ポリシーはサポートされていません。 パイプラインの実行は他の実行からは独立しており、認識できません。 言い換えると、2 つの連続するコミットによって 2 つのパイプラインがトリガーされる可能性があり、両方が互いを待たずに同じ一連のステージを実行します。 キュー ポリシーを YAML パイプラインに取り込む作業を行う一方で、手動による 承認 を使用して、これが重要な場合に実行の順序を手動でシーケンスして制御することをお勧めします。

承認チェックを使用することにより、ステージを実行するタイミングを手動で制御できます。 これは一般的に、運用環境へのデプロイを制御するために使用されます。 チェックは、パイプライン内のステージがリソースを使用できるかどうかを制御するためにリソース 所有者 が使用できるメカニズムです。 環境などのリソースの所有者は、そのリソースを消費するステージを開始する前に満たす必要があるチェックを定義できます。

現在、環境では手動承認チェックがサポートされています。 詳細については、「 承認」を参照してください。