次の方法で共有

リリース トリガー

  • [アーティクル]

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

Note

このトピックでは、クラシック リリース パイプラインについて説明します。 YAML パイプラインのトリガーについては、パイプライン トリガーに関する記事を参照してください。

リリース トリガーは、アプリケーションをデプロイするための自動化ツールです。 トリガー条件が満たされると、パイプラインによって、既に指定した環境/ステージに成果物がデプロイされます。

継続的デプロイ トリガー

継続的デプロイ トリガーでは、新しいビルド成果物が使用可能になるたびにリリースを作成できます。 ビルド ブランチ フィルターを使用すると、特定のターゲット ブランチのデプロイをトリガーできます。 リリースは、指定されたブランチのコミットが Git プッシュに含まれている場合にのみトリガーされます。 たとえば、main を選択すると、メイン ブランチへの 1 つ以上のコミットを含む Git プッシュのリリースがトリガーされます。 features/ のブランチへのコミットに対してリリースをトリガーするには、「features/*」と入力します。 すべてのブランチへのコミットのリリースをトリガーするには、「*」と入力します。 指定されたすべてのフィルターは OR に設定されることに注意してください。

継続的デプロイ トリガーを構成する

注意

リリースを自動的に作成しても、ステージに自動的にデプロイされるわけではありません。 さまざまなステージにアプリをデプロイするためのトリガーを設定する必要があります。

スケジュール済みのリリース トリガー

スケジュールされたリリース トリガーを使用すると、特定の時刻に新しいリリースを作成できます。

[成果物] セクションの下にあるスケジュール アイコンを選択します。 [有効/無効] ボタンを切り替え、リリース スケジュールを指定します。 リリースをトリガーする複数のスケジュールを設定できます。

リリースをトリガーするスケジュールを定義する

pull request トリガー

pull request トリガーを有効にする場合、選択した成果物が pull request ワークフローの一部として使用可能になるたびにリリースが作成されます。

pull request トリガーを構成します。

pull request トリガーを使用するには、特定のステージでも有効にする必要があります。 次のセクションでは、ステージ トリガーについて説明します。 ブランチのブランチ ポリシーを設定することもできます。

ビルド タグを使用して、ワークフローを整理し、特定の実行にタグを付けることもできます。 次の pull request トリガーは、新しい成果物バージョンが、"移行" と "デプロイ" というタグを持つ "メイン" ブランチへの pull request の一部として使用できるようになるたびにリリースを作成します。

ビルド タグを使用して pull request トリガーを設定する方法の例を示すスクリーンショット

ステージ トリガー

ステージ トリガーでは、特定のステージへのデプロイをトリガーする特定の条件を設定できます。

  • トリガーの選択: デプロイを開始するトリガーをステージに自動的に設定します。 [ステージ] ドロップダウンを使用して、選択したステージへのデプロイが成功した後にリリースをトリガーします。 手動トリガーのみを許可するには、[手動のみ] を選択します。

    デプロイ前のトリガーを示すスクリーンショット。

  • 成果物フィルター: トグル ボタンを有効にして、特定の成果物に基づいて新しいデプロイをトリガーします。 この例では、指定したブランチから新しい成果物を入手できる場合、リリースがデプロイされます。

    デプロイ前のアーティファクト フィルターを示すスクリーンショット。

  • スケジュール: 特定の時刻に、指定したステージへの新しいデプロイをトリガーします。

    デプロイ前のスケジュール設定を示すスクリーンショット。

  • pull request のデプロイ: 新しい pull request が作成されるたびに新しいリリースをトリガーするトグル ボタンを有効にします。 運用環境では、この機能を無効にすることをお勧めします。

    pull request のデプロイ トリガーを示すスクリーンショット。

  • デプロイ前の承認: 選択したステージへのデプロイを承認または拒否できるユーザーを選択します。 既定では、この機能が有効になっている場合、すべてのプロジェクト ユーザーがデプロイを承認する必要があります。 承認者リストにグループが追加された場合、グループ内の少なくとも 1 人のユーザーがデプロイを承認する必要があります。 "承認ポリシー" と "タイムアウト" (自動的に拒否されるまでの保留中の状態を維持するための最大時間) を指定することもできます。

    デプロイ前の承認を示すスクリーンショット。

  • ゲート: トグル ボタンを有効にして、トリガーのデプロイ前に評価する特定のゲートを設定します。

    デプロイ前のゲートを示すスクリーンショット。

  • デプロイ キューの設定:

複数のリリースがデプロイのためにキューに入れられている場合の特定のアクションを構成します。

デプロイ キューの設定を示すスクリーンショット。

  • 並列デプロイの数: オプション: [Specific] (指定) または [Unlimited] (無制限)。 同じステージ内で同時に実行できるデプロイの数を指定します。 この数を「1」に設定すると、デプロイが順番に実行されます。

  • 以降のリリース: オプション: [Deploy all in sequence] (順番にすべてをデプロイする) または [Deploy latest and cancel the others] (最新版のみをデプロイしてその他はキャンセルする)。[Number of parallel deployments] (並列デプロイの数) の下にある [Specific] (指定) を選択するとこのオプションがアクティブになります。

    • Deploy all in sequence (順番にすべてをデプロイする): リリースを順番にデプロイする必要がある場合は、このオプションを選択します。 この方法では、デプロイ前の承認要求が正しい順序で処理されます。

    • Deploy latest and cancel the others (最新版のみをデプロイしてその他はキャンセルする): リリースよりも速くビルドを生成しており、最新のビルドのみをデプロイしたい場合にこのオプションを選択します。 詳細については、「キュー ポリシーを指定する」を参照してください。