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

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

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

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

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

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

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

YAML

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

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

クラシック

リリース パイプラインにステージを追加するには、[Release] (リリース) ページでリリース パイプラインを選択し、アクションを選択して [Edit] (編集) を行い、[Pipeline] (パイプライン) タブを選択します。ステージの定義において最も重要な部分は自動化タスクですが、リリース パイプラインのステージに対していくつかのプロパティとオプションを構成することもできます。 次の操作を行います。

• 必要に応じて、ここでステージの名前を編集する。
• ステージ所有者として 1 人のユーザーまたは 1 つのグループを指定する。 そのステージへのデプロイが失敗すると、ステージ所有者は通知を受け取ります。 ステージ所有者になっても、アクセス許可は自動的に付与されません。
• パイプラインからステージを削除する。
• ステージの順番を変更する。
• ステージのコピーを ステージ テンプレートとして保存する。
• ステージのセキュリティ設定を管理する。

依存関係を指定する

YAML

パイプラインで複数のステージを定義すると、既定では、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

クラシック

依存関係を制御する場合は、リリース パイプラインの各ステージでトリガーを設定します。

• ステージは、トリガーを使用して、または手動で開始することによって実行されます。
• リリース後のトリガーを使用して、リリースが開始されるとすぐに、リリース後のトリガーを持つその他のステージと並行してステージが開始されます。
• [After stage] (ステージ後) トリガーの場合、ステージは依存するすべてのステージが完了した後に開始されます。 これを使用して、ステージのファンアウトとファンインの動作をモデル化できます。

条件を定義する

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

ステージのための先行の手順の既定の条件をカスタマイズする場合は、完了と成功の条件を削除します。 そのため、カスタム条件を使用する場合は、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'))

クラシック

[After release] (リリース後) または [After stage] (ステージの後) トリガーを指定する場合は、リリースで使用される成果物のブランチ フィルターを指定することもできます。 リリースは、ブランチ フィルターが満たされた場合にのみステージにデプロイされます。

キュー ポリシーを指定する

YAML

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

クラシック

場合によっては、デプロイするよりも速くビルドを生成できる場合があります。 または、複数のエージェントを構成して、たとえば、異なる成果物のデプロイのために同じリリース パイプラインからリリースを作成することもできます。 このような場合は、複数のリリースを 1 つのステージのキューに入れる方法を制御できると便利です。 キュー ポリシーによってその制御を行えます。

キュー ポリシーのために選択できるオプションは次のとおりです。

• [Number of parallel deployments] (並列デプロイの数): ステージで新しいリソースを動的にプロビジョニングし、かつ複数のリリースのデプロイを処理することが物理的に可能であるものの並列デプロイの数を制限したい場合は、このオプションを使用します。

• デプロイの最大数を指定すると、さらに 2 つのオプションが表示されます。

  • [Deploy all in sequence] (順番にすべてをデプロイする): すべてのリリースを同じ共有物理リソースに順番にデプロイする場合は、このオプションを使用します。 ビルドを順番にデプロイすることで、複数のビルドおよびリリース エージェントが使用可能であっても、2 つのデプロイ ジョブが同じ物理リソースを同時にターゲットにしないようにできます。 また、ステージのデプロイ前承認要求が順番に送信されることを確認してください。

  • 最新版のみを配置してその他はキャンセルする: このオプションは、リリースよりも速くビルドを生成しており、最新のビルドのみをデプロイしたい場合に使用します。

これらのオプションの仕組みを理解するために、1 つのリリース パイプラインのリリースである R1、R2、...、R5 が連続して作成されるシナリオを検討してください。 このパイプラインの最初のステージの名前は QA で、デプロイ前とデプロイ後の両方の承認者が定義されています。

• 並列デプロイ数の制限を指定しない場合、リリースが作成されるとすぐに 5 個の承認要求がすべて送信されます。 承認者がすべてのリリースを承認した場合、それらはすべて QA ステージに並行してデプロイされます。 (QA ステージにデプロイ前承認者が定義されていない場合、5 個のリリースはすべてこのステージと並列に自動的にデプロイされます)

• 制限を指定してすべて順番にデプロイを実行し、その制限にすでに達している場合は、リリース R1 のデプロイ前承認が最初に送信されます。 この承認が完了すると、QA ステージへのリリース R1 のデプロイが開始されます。 次に、リリース R1 に対してデプロイ後の承認要求が送信されます。 このデプロイ後の承認が完了した後にのみ、リリース R2 の実行が開始され、そのデプロイ前の承認が送信されます。このプロセスは、すべてのリリースに対してこのように順番に続行されます。

• 制限を指定して最新をデプロイし、その他をキャンセルして、その制限にすでに達している場合は、リリース R2、R3、および R4 はスキップされ、QA ステージの R5 のデプロイ前承認は、リリース R1 が完了された直後に送信されます。

承認を指定する

YAML

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

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

クラシック

パイプラインの各ステージの開始時または終了時に手動承認を追加できます。 詳細については、リリースの承認とゲートの概要に関するページを参照してください。