クラシック パイプラインを定義する
Azure DevOps Services |Azure DevOps Server 2022 - Azure DevOps Server 2019 |TFS 2018
Note
Microsoft Team Foundation Server (TFS) 2018 以前のバージョンでは、ビルドとリリースの "パイプライン" は "定義"、"実行" は "ビルド"、"サービス接続" は "サービス エンドポイント"、"ステージ" は "環境"、"ジョブ" は "フェーズ" と呼ばれます。
Azure Pipelines は、開発、ステージング、QA、運用などの複数のステージへのリリースに対して、高度に構成可能で管理しやすいパイプラインを提供します。 また、各ステージでゲートと承認を実装する機会も提供します。
このチュートリアルでは、次の事項について説明します。
- 継続的デプロイ トリガー
- ステージの追加
- デプロイ前の承認の追加
- リリースの作成とデプロイの監視
前提条件
必要なものは次のとおりです。
少なくとも 1 つのステージを含むリリース パイプライン。 まだお持ちでない場合は、次のクイックスタートとチュートリアルのいずれかを使用して作成できます。
アプリをデプロイする 2 つの個別のターゲット。 これらは、仮想マシン、Web サーバー、オンプレミスの物理デプロイ グループ、またはその他の種類のデプロイ ターゲットです。 この例では、Azure App Service Web サイト インスタンスを使用しています。 同じ操作を行う場合は、一意の名前を選択する必要がありますが、簡単に識別できるように、名前に "QA" を含め、もう一方の名前に "Production" を含めることをお勧めします。 Azure portalを使用して新しい Web アプリを作成します。
継続的デプロイ (CD) トリガー
継続的デプロイ トリガーを有効にすると、新しいビルドが使用可能になるたびに新しいリリースを自動的に作成するようにパイプラインに指示されます。
Azure Pipelines で、[リリース] タブを開きます。リリース パイプラインを選択して[編集]を選択します。
[成果物] セクションで [継続的デプロイ トリガー] アイコンを選択して、トリガー パネルを開きます。 新しいビルドが正常に完了するたびに新しいリリースが作成されるように、これが有効になっていることを確認します。
[ステージ] セクションの [デプロイ前の条件] アイコンを選択して、条件パネルを開きます。 このステージへのデプロイのトリガーが [ リリース後] に設定されていることを確認します。 つまり、このリリース パイプラインから新しいリリースが作成されると、デプロイが自動的に開始されます。
リリース トリガー、ステージ トリガー、またはデプロイのスケジュールを設定することもできます。
ステージ (複数) を追加
このセクションでは、リリース パイプラインに QA と運用の 2 つの新しいステージを追加します (この例では、2 つのAzure アプリ Services Web サイト)。 これは、テスト サーバーまたはステージング サーバーに最初にデプロイし、次にライブ サーバーまたは実稼働サーバーにデプロイする一般的なシナリオです。 各 ステージ は、1 つのデプロイ ターゲットを表します。
リリース パイプラインで [ パイプライン ] タブを選択し、既存のステージを選択します。 ステージの名前を 運用環境に変更します。
![[パイプライン] タブから既存のステージを選択し、[ステージ] パネルで名前を [運用] に変更する](media/define-multistage-release-process/rename-environment-prod.png?view=azure-devops)
[ + 追加] ドロップダウン リストを選択し、[ 複製ステージ ] を選択します (複製オプションは、既存のステージが選択されている場合にのみ使用できます)。
通常は、デプロイされたアプリが同じように動作することを確認できるように、テストと運用ステージで同じデプロイ方法を使用する必要があります。 既存のステージを複製すると、両方の設定が同じになるようにすることをお勧めします。 その後、デプロイ ターゲットを変更するだけです。
複製されたステージには、 運用のコピーという名前が付けられます。 それを選択し、名前を QA に変更します。
パイプラインのステージを再編成するには、QA ステージでデプロイ前の条件アイコンを選択し、トリガーをリリース後に設定します。 パイプラインダイアグラムには、2 つのステージが並列に表示されます。
運用ステージで [デプロイ前の条件] アイコンを選択し、トリガーを [ステージの後] に設定し、[ステージ] ドロップダウン リストで [QA] を選択します。 パイプラインダイアグラムは、2 つのステージが正しい順序で実行されることを示します。
Note
前のステージへのデプロイが 部分的に 成功したときに開始するようにデプロイを設定できます。 つまり、特定の重要でないタスクが失敗した場合でも、デプロイは続行されます。 これは通常、異なるステージに並列にデプロイするフォークデプロイと参加デプロイで使用されます。
[タスク] ドロップダウン リストを選択し、QA ステージを選択します。
使用しているタスクに応じて、このステージが "QA" ターゲットにデプロイされるように設定を変更します。 この例では、次に示すように、deploy Azure App Service タスクを使用します。
デプロイ前の承認を追加する
以前に変更したリリース パイプラインは、QA と運用にデプロイします。 QA へのデプロイが失敗した場合、運用環境へのデプロイはトリガーされません。 運用環境にデプロイする前に、アプリが QA またはテスト ステージで適切に動作しているかどうかを常に確認することをお勧めします。 承認を追加すると、次のステージにデプロイする前にすべての条件が満たされます。 パイプラインに承認を追加するには、次の手順に従います。
[ パイプライン ] タブ、 展開前条件 アイコン、展開 前承認者の順に選択します。
[ 承認者 ] テキスト ボックスに、展開を承認するユーザーを入力します。 また、[ リリースまたはデプロイを要求しているユーザーが承認しない] チェック ボックスをオフにすることもお勧めします。
個々のユーザーと組織グループの両方で、必要な数の承認者を追加できます。 パイプライン図のステージの右側にある [ユーザー] アイコンを選択して、デプロイ後の承認を設定することもできます。 詳細については、「 リリースのゲートと承認」を参照してください。
[保存] を選択します。
リリースを作成する
リリース パイプラインのセットアップが完了したら、デプロイを開始します。 これを行うには、新しいリリースを手動で作成します。 通常、新しいビルド成果物が使用可能になると、リリースが自動的に作成されます。 ただし、このシナリオでは手動で作成します。
[ リリース ] ドロップダウン リストを選択し、[ リリースの作成] を選択します。
リリースの説明を入力し、正しい成果物が選択されていることを確認し、[ 作成] を選択します。
新しいリリースが作成されたことを示すバナーが表示されます。 リリース リンクを選択すると、詳細が表示されます。
リリースの概要ページには、各ステージへのデプロイの状態が表示されます。
リリースの一覧など、その他のビューにも、承認待ちであることを示すアイコンが表示されます。 アイコンには、ステージ名と、それをポイントしたときの詳細を含むポップアップが表示されます。 これにより、管理者が、承認待ちのリリースとすべてのリリースの全体的な進行状況を容易に確認できます。
pending_approval アイコンを選択して、承認ウィンドウ パネルを開きます。 簡単なコメントを入力し、[ 承認] を選択します。
Note
ピーク時以外の時間帯など、後でデプロイをスケジュールできます。 承認を別のユーザーに再割り当てすることもできます。 リリース管理者は、すべての承認決定にアクセスしてオーバーライドできます。
デプロイを監視および追跡する
デプロイ ログは、アプリケーションのリリースを監視およびデバッグするのに役立ちます。 デプロイのログを確認するには、次の手順に従います。
リリースの概要で、ステージにカーソルを合わせて [ログ] を選択 します。
デプロイ中でも、ログ ページにアクセスして、すべてのタスクのライブ ログを確認できます。
任意のタスクを選択して、その特定のタスクのログを表示します。 これにより、デプロイの問題のトレースとデバッグが容易になります。 個々のタスク ログ、またはすべてのログ ファイルの zip をダウンロードすることもできます。
デプロイをデバッグするために追加情報が必要な場合は、 デバッグ モードでリリースを実行できます。