次の方法で共有

ステージ、依存関係、条件の追加

  • [アーティクル]

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

ステージは、Azure DevOps パイプライン内の論理境界です。 ステージを使用して、ソフトウェア開発プロセスのアクションをグループ化できます (たとえば、アプリの構築、テストの実行、運用前へのデプロイなど)。 各ステージには、1 つ以上のジョブが含まれます。

パイプラインで複数のステージを定義すると、既定では 1 つずつ実行されます。 ステージィは相互に依存させることができます。 dependsOn キーワードを使用して依存関係を定義できます。 ステージは、条件付きで前のステージの結果に基づいて実行することもできます。

ステージが並列ジョブおよびライセンスとどのように連携するかについては、「並列ジョブの構成と支払い」を参照してください。

ステージとパイプラインの他の部分 (ジョブなど) との関係については、主要なパイプラインの概念に関するページを参照してください。

ステージとパイプラインの各部分との関係については、YAML スキーマ ステージに関する記事も参考になります。

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

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

Note

ステージのサポートは、Azure DevOps Server 2019.1 で追加されました。

ステージを指定する

注意

ステージのサポートは、Azure DevOps Server 2019.1 で追加されました。

最も単純な状況では、パイプラインに論理境界は必要ありません。 その場合、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 を指定することを選択した場合、ステージ レベルで指定されていない限り、そのステージで定義されているすべてのジョブは、そのプールを使用します。

Note

Azure DevOps Server 2019 では、プールはジョブ レベルでのみ指定できます。

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]

依存関係を指定する

注意

ステージのサポートは、Azure DevOps Server 2019.1 で追加されました。

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

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

複数のステージとその依存関係を定義するための構文は次のとおりです。

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

条件を定義する

式を使用して、各ステージを実行する条件を指定できます。 既定では、ステージが他のステージに依存していない場合、または依存するすべてのステージが完了して成功した場合に、ステージが実行されます。 この動作をカスタマイズするには、前のステージが失敗した場合でもステージを強制的に実行するか、カスタム条件を指定します。

ステージのための先行の手順の既定の条件をカスタマイズする場合は、完了と成功の条件を削除します。 そのため、カスタム条件を使用する場合は、and(succeeded(),custom_condition) を使用して先行のステージが正常に実行されたかどうかをチェックするのが一般的です。 それ以外の場合は、先行のステージの結果に関係なくステージが実行されます。

注意

次の例に示すように、失敗した ('JOBNAME/STAGENAME') と成功した ('JOBNAME/STAGENAME') の条件は、YAML パイプラインでのみ機能します。

注意

ステージのサポートは、Azure DevOps Server 2019.1 で追加されました。

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

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 つのパイプラインがトリガーされる可能性があり、両方とも互いを待たずに同じ一連のステージを実行します。 このことが重要である場合は、Microsoft がキュー ポリシーを YAML パイプラインに実装するまでは、手動による承認を使用して実行の順序を手動で順序付けして制御することをお勧めします。

承認を指定する

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

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

このバージョンの Azure DevOps Server では、YAML パイプラインでの承認はまだサポートされていません。

手動トリガーを追加する

手動でトリガーされる YAML パイプライン ステージでは、常に完了まで実行することなく、統合パイプラインを作成できます。

たとえば、パイプラインには、ビルド、テスト、ステージング環境へのデプロイ、本番環境へのデプロイのためのステージが含まれる場合があります。 準備ができたら手動でトリガーする本番デプロイを除き、すべてのステージを自動的に実行できます。

この機能を使用するには、trigger: manual プロパティをステージに追加します。

次の例では、開発ステージが自動的に実行されますが、本番ステージは手動でトリガーする必要があります。 どちらのステージでも、hello world 出力スクリプトが実行されます。

stages:
- stage: development
  displayName: Deploy to development
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'
- stage: production
  displayName: Deploy to production
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'

ステージをスキップ不可としてマークする

パイプライン ユーザーがステージをスキップできないように、ステージを isSkippable: false としてマークします。 たとえば、すべてのパイプラインでマルウェア検出を実行するステージを挿入する YAML テンプレートがあるとします。 このステージに isSkippable: false 設定した場合、パイプラインではマルウェア検出をスキップできません。

次の例では、マルウェア検出ステージがスキップ不可としてマークされています。つまり、パイプライン実行の一部として実行する必要があります。

- stage: malware_detection
  displayName: Malware detection
  isSkippable: false
  jobs:
  - job: check_job
    ...

ステージがスキップ不可の場合、[実行するステージ] 構成パネルに無効になっているチェックボックスが表示されます。

無効になっているステージで実行するステージのスクリーンショット。