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

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

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

よく寄せられる質問

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 というリリースが作成されます。

変数	説明
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: リリース パイプラインの保持ポリシーを設定する方法については、保持ポリシーに関する記事を参照してください。

関連記事

• プル要求成果物のデプロイ
• 複数のブランチからのデプロイ
• 複数ステージのリリース パイプラインを設定する