次の方法で共有

クラシック リリース パイプライン

  • [アーティクル]

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

クラシック リリース パイプラインを使用すると、開発者には複数の環境にアプリケーションを効率的かつ安全にデプロイするためのフレームワークが提供されます。 クラシック リリース パイプラインを使用すると、テストとデプロイプロセスを自動化し、柔軟なデプロイ戦略を設定し、承認ワークフローを組み込み、さまざまな段階でアプリケーションのスムーズな移行を確実に行うことができます。

リリース パイプラインのしくみ

Azure Pipelines では、すべてのデプロイの一部として次の手順が実行されます。

  1. デプロイ前に承認する:

    新しいデプロイ要求がトリガーされると、Azure Pipelines は、リリースをステージにデプロイする前に、デプロイ前の承認が必要かどうかを確認します。 承認が必要な場合、適切な承認者に電子メールによる通知が送信されます。

  2. デプロイ ジョブをキューに入れる:

    Azure Pipelines では、使用可能なエージェントにデプロイ ジョブをスケジュールします。

  3. エージェントを選択する:

    使用可能なエージェントがデプロイ ジョブを選択します。 リリース パイプラインは、実行時に適切なエージェントを動的に選択するように構成できます。

  4. 成果物をダウンロードする:

    エージェントは、リリースで指定されたすべての成果物を取得してダウンロードします。

  5. デプロイ タスクを実行する:

    エージェントは、デプロイ ジョブ内のすべてのタスクを実行します。

  6. 進行状況ログを生成する:

    エージェントは、デプロイ手順ごとに包括的なログを生成し、Azure Pipelines に送り返します。

  7. 展開後の承認:

    ステージへのデプロイが完了すると、Azure Pipelines は、その特定のステージにデプロイ後の承認が必要かどうかを確認します。 承認が必要ない場合、または必要な承認が取得されると、次のステージへのデプロイの開始に進みます。

Azure Pipelines でのデプロイ手順を示すスクリーンショット。

デプロイ モデル

Azure リリース パイプラインでは、Jenkins、Azure Artifacts、Team City など、さまざまな成果物ソースがサポートされています。 次の例は、Azure リリース パイプラインを使用したデプロイ モデルを示しています。

次の例では、パイプラインは、個別のビルド パイプラインから生成された 2 つのビルド成果物で構成されています。 アプリケーションは最初に開発ステージにデプロイされ、2 つの QA ステージにデプロイされます。 両方の QA ステージでデプロイが成功すると、アプリケーションは運用リング 1、その次に運用リング 2 にデプロイされます。 各運用リングは、世界中のさまざまな場所にデプロイされた同じ Web アプリの複数のインスタンスを表します。

リリース パイプラインのデプロイ手順を示すスクリーンショット。

リリースとデプロイ

リリースとは、CI/CD パイプラインで指定された一連のバージョン付き成果物を保持するコンストラクトのことです。 これには、ステージ、タスク、ポリシー (トリガーや承認者など)、デプロイ オプションなど、リリース パイプライン内のすべてのタスクとアクションを実行するために必要なすべての情報のスナップショットが含まれます。 1 つのリリース パイプラインからのリリースが複数存在する場合があり、それぞれについての情報が、指定された保持期間にわたって Azure Pipelines に格納および表示されます。

デプロイとは、1 つのステージのタスクを実行するアクションのことです。これには、自動テストの実行、ビルド成果物のデプロイ、およびそのステージに指定されている他のあらゆるアクションが含まれます。 リリースを開始すると、元のリリース パイプラインで定義されている設定とポリシーに基づいて各デプロイが開始されます。 1 つのステージであっても、各リリースを複数回デプロイする場合があります。 1 つのステージでリリースのデプロイが失敗した場合は、同じリリースをそのステージに再デプロイできます。 リリースの再デプロイは、デプロイするリリースに移動して [デプロイ] を選択するだけで実行できます。

次の図は、リリース、リリース パイプライン、デプロイの関係を示しています。

リリースとデプロイの違いを示す図。

よく寄せられる質問

Q: デプロイがトリガーされなかったのはなぜですか?

A: リリース パイプラインを作成しても、デプロイは自動的に開始されません。 これが発生する理由は次のとおりです。

  • デプロイ トリガー: 定義されたデプロイ トリガーにより、デプロイが一時停止する可能性があります。 これは、スケジュールされたトリガーや、別のステージへのデプロイが完了するまで遅延が発生した場合に発生する可能性があります。

  • キュー ポリシー: これらのポリシーは、実行の順序と、リリースがデプロイのためにキューに登録されるタイミングを決定します。

  • 展開前の承認またはゲート: 特定のステージでは、展開前の承認またはゲートが必要になる場合があり、定義されているすべての条件が満たされるまでデプロイが妨げられます。

Q: リリース時に変数を編集するにはどうすればよいですか?

A: リリース パイプラインの [変数] タブで、リリースがキューに登録されるときに編集する変数に対して、[リリース時に設定可能] チェックボックスを選択します。

[リリース時に設定可能] 機能を有効にする方法を示すスクリーンショット。

その後、新しいリリースを生成するときに、これらの変数の値を変更できます。

リリース時に変数を編集する方法を示すスクリーンショット。

Q: リリースを定義するパイプラインの代わりに、リリースを変更する方が適切なタイミングはいつですか?

A: リリース インスタンスの承認、タスク、変数を編集できます。 ただし、これらの編集は、そのインスタンスのみに適用されます。 将来のすべてのリリースに適用する場合は、代わりにリリース パイプラインを編集します。

Q: [リリースを破棄する] 機能が役立つシナリオは何ですか?

A: リリースを再利用する予定がない場合、またはリリースが使用されないようにする場合は、[パイプライン]> 省略記号 (...) >[破棄] の順に選択して、リリースを破棄できます。 デプロイの進行中にリリースを破棄することはできません。最初にデプロイを取り消す必要があります。

リリースを破棄する方法を示すスクリーンショット。

Q: 新しいリリースの名前を管理するにはどうすればよいですか?

A: リリース パイプラインの既定の名前付け規則は順次番号付けであり、リリースの名前 は Release-1、Release-2 などです。 ただし、リリース名の形式マスクを変更することで、名前付けスキームを柔軟にカスタマイズできます。 リリース パイプラインの [オプション] タブで、[全般] ページに移動し、設定に合わせて [リリース名の形式] プロパティを調整します。

形式マスクを指定する場合は、次の定義済みの変数を使用できます。 例: Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName) というリリース名の形式では、Release 002 for build 20170213.2 MySampleAppBuild というリリースが作成されます。

Variable 説明
Rev: rr 指定した桁数以上の自動的にインクリメントされる数値。
Date/Date: MMddyy 現在の日付。既定の形式は MMddyy です。 M/MM/MMM/MMMM、d/dd/ddd/dddd、y/yy/yyyy/yyyy、h/hh/H/HH、m/㎜、s/ss の任意の組み合わせがサポートされています。
System.TeamProject ビルドが属するチーム プロジェクトの名前。
Release.ReleaseId リリースの ID。プロジェクト内のすべてのリリース間で一意です。
Release.DefinitionName 現在のリリースが所属するリリース パイプラインの名前。
Build.BuildNumber リリースに含まれるビルドの番号。 リリースに複数のビルドがある場合は、プライマリ ビルドの番号です。
Build.DefinitionName リリースに含まれるビルドのパイプライン名。 リリースに複数のビルドがある場合は、プライマリ ビルドのパイプライン名です。
Artifact.ArtifactType リリースにリンクされている成果物ソースの種類。 たとえば、Azure Pipelines や Jenkins などです。
Build.SourceBranch プライマリ成果物ソースのブランチ。 Git の場合、分岐が refs/head/main の場合、これは main という形式になります。 Team Foundation バージョン管理の場合、ワークスペースのルート サーバー パスが $/teamproject/branch であれば、これは branch という形式になります。 この変数は、Jenkins またはその他の成果物ソースに対しては設定されません。
カスタム変数 リリース パイプラインで定義されているグローバル構成プロパティの値。 リリース ログ コマンドを使用して、カスタム変数でリリース名を更新できます

Q: リリースの保持期間を定義するにはどうすればできますか?

A: リリース パイプラインの保持ポリシーを設定する方法については、保持ポリシーに関する記事を参照してください。