Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022
クラシック リリース パイプラインは、セキュリティで保護された信頼性の高い方法で複数の環境にアプリケーションをデプロイするのに役立ちます。 クラシック リリース パイプラインを使用すると、テストとデプロイの自動化、柔軟なデプロイ戦略の定義、承認ゲートの追加、ステージ間でのデプロイの管理を行うことができます。
[前提条件]
| 製品 | 必要条件 |
|---|---|
| Azure DevOps | - Azure DevOps 組織。 - Azure DevOps プロジェクト。 |
リリース パイプラインのしくみ
デプロイごとに、Azure Pipelines は次の一連の手順を実行します。
デプロイ前に承認する:
デプロイがトリガーされると、Azure Pipelines は、ステージにデプロイ前の承認が必要かどうかを確認します。 承認が必要な場合は、構成された承認者に通知を送信し、承認を待ってから続行します。
デプロイ ジョブをキューに追加する
Azure Pipelines は、デプロイ ジョブをキューに入れ、使用可能な エージェントでスケジュールします。
エージェントを選択します。
使用可能なエージェントがデプロイメント ジョブを受け持ちます。 リリース パイプラインは、実行時に適切なエージェントを動的に選択するように構成できます。
成果物をダウンロードする:
エージェントは、リリースに関連付けられているすべての成果物をダウンロードします。
デプロイ タスクを実行します。
エージェントは、ステージのデプロイ ジョブで定義されているタスクを実行します。
デプロイ ログを生成します。
エージェントは、デプロイ 手順ごとに詳細なログを生成し、Azure Pipelines に送り返します。
展開後の承認:
ステージへのデプロイが完了すると、Azure Pipelines はデプロイ後の承認が必要かどうかを確認します。 承認が付与されるか、承認が必要ない場合は、パイプラインは次のステージに進みます。
デプロイ モデル
Azure リリース パイプラインでは、Jenkins、Azure Artifacts、Team City など、さまざまな成果物ソースがサポートされています。 この柔軟性により、複数のビルド システムと環境にまたがるデプロイ モデルを設計できます。 次の例は、Azure リリース パイプラインを使用したデプロイ モデルを示しています。
このモデルでは、リリース パイプラインは、個別のビルド パイプラインによって生成された 2 つのビルド 成果物を使用します。 アプリケーションは最初に開発ステージにデプロイされ、次に 2 つの並列 QA ステージにデプロイされます。 両方の QA ステージでアプリケーションが正常に検証されると、 Prod リング 1 にデプロイされ、その後 Prod リング 2 にデプロイされます。
各運用リングは、異なる地理的な場所にデプロイされた同じ Web アプリケーションの複数のインスタンスを表します。 このリングベースのアプローチにより、段階的なロールアウト、検証の制御、運用デプロイ中のリスクの軽減が可能になります。
リリースとデプロイ
リリースは、CI/CD パイプラインで指定された成果物のバージョン管理されたセットを保持するコンストラクトです。 これには、ステージ、タスク、ポリシー、デプロイ オプションなど、リリース パイプライン内のすべてのタスクとアクションを実行するために必要なすべての情報のスナップショットが含まれています。
1 つのリリース パイプラインで複数のリリースを生成できます。 Azure Pipelines は、各リリースに関する情報を格納し、指定された 保有期間にわたって表示します。
デプロイとは、リリース内の単一ステージに対して定義されたタスクの実行です。 デプロイには、自動テストの実行、ビルド成果物のデプロイ、そのステージ用に構成されたその他のタスクの実行などのアクションを含めることができます。 リリースを作成すると、Azure Pipelines は、リリース パイプラインで定義されているポリシーと設定に基づいてデプロイを開始します。 リリースは、同じステージに複数回デプロイできます。 ステージのデプロイが失敗した場合は、リリースから [デプロイ] を選択して、同じリリースをそのステージに再デプロイできます。
次の図は、リリース パイプライン、リリース、デプロイの関係を示しています。
