クラシック パイプラインを定義する

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

Azure Pipelines が提供するパイプラインは自由に構成でき、管理性にも優れ、開発、ステージング、QA、運用など、さまざまなステージへのリリースに使用できます。 また、特定の各段階でゲートと承認を実装する機会も設けられています。

このチュートリアルで学習する内容は次のとおりです。

• 継続的デプロイ トリガー
• ステージの追加
• デプロイ前の承認の追加
• リリースの作成とデプロイの監視

前提条件

必要なものは次のとおりです。

• 少なくとも 1 つのステージを含むリリース パイプライン。 まだ 1 つもステージをお持ちでない場合は、次のクイックスタートとチュートリアルのいずれかに沿って作成できます:

  • Azure Web アプリにデプロイする
  • Azure DevOps プロジェクト
  • Windows 上の IIS Web サーバーにデプロイする

• アプリのデプロイ先となる 2 つの個別のターゲット。 このターゲットとなるのは、仮想マシン、Web サーバー、オンプレミスの物理デプロイ グループ、またはその他の種類のデプロイ ターゲットなどです。 この例では、Azure App Service の Web サイト インスタンスを使用しています。 同じことを行う場合は、一意の名前を選択する必要がありますが、簡単に識別できるように、一方の名前に「QA」を含め、もう一方の名前に「Production」を含めることをお勧めします。 Azure portal を使用して新しい Web アプリを作成します。

継続的デプロイ (CD) トリガー

継続的デプロイ トリガーを有効にすると、新しいビルドが使用可能になるたびに新しいリリースを自動的に作成するように、パイプラインが指示されます。

1. Azure Pipelines で [リリース] タブを開きます。リリース パイプラインを選択して、[編集] を選択します。

   

2. [成果物] セクションで [継続的デプロイ トリガー] アイコンを選択して、トリガー パネルを開きます。 これが有効になっていることを確認します。有効になっていれば、新しいビルドが正常に完了するたびに新しいリリースが作成されます。

   

3. [ステージ] セクションで [デプロイ前条件] アイコンを選択して、条件パネルを開きます。 このステージへのデプロイのトリガーが [リリース後] に設定されていることを確認します。 この設定によって、このリリース パイプラインから新しいリリースが作成されると、デプロイが自動的に開始されます。

   

   また、リリース トリガー、ステージ トリガー、またはデプロイのスケジュールを設定することもできます。

ステージ (複数) を追加

このセクションでは、リリース パイプラインに QA と運用という 2 つの新しいステージ (この例では、2 つの Azure App Services の Web サイト) を追加します。 これは、最初にテスト サーバーまたはステージング サーバーにデプロイした後にライブ サーバーまたは運用サーバーにデプロイする、一般的なシナリオです。 ステージはそれぞれ、1 つのデプロイ ターゲットを表します。

1. リリース パイプラインで [パイプライン] タブを選択し、既存のステージを選択します。 ステージの名前を「Production」に変更します。

   

2. [+ 追加] ドロップダウン リストを選択し、[ステージの複製] を選択します (複製オプションは、既存のステージが選択されている場合にのみ使用できます)。

   

   通常は、テスト ステージと運用ステージで同じデプロイ方法を使用することにより、デプロイされたアプリが同じように動作することを確認できるようにします。 両方の設定が確実に同じにするための良い方法は、既存のステージを複製することです。 その後、デプロイ ターゲットを変更すればよいだけです。

3. 複製されたステージの名前は「Copy of Production」になります。 それを選択して名前を「QA」に変更します。

   

4. パイプライン内のステージを再構成するには、QA ステージで [デプロイ前条件] アイコンを選択し、トリガーを [リリース後] に設定します。 パイプライン図には、2 つのステージが並列で表示されます。

   

5. [運用] ステージで [デプロイ前条件] アイコンを選択し、トリガーを [ステージの後] に設定し、[ステージ] ドロップダウン リストで [QA] を選択します。 パイプライン図が、2 つのステージが正しい順序で実行されることを示します。

   

   注意

   前のステージへのデプロイが"部分的に"成功したときに開始するように、デプロイを設定できます。 つまり、特定の重要でないタスクが失敗した場合でも、デプロイは続行します。 これは通常、異なるステージに並列にデプロイする、フォークと結合デプロイで使用されます。

6. [タスク] ドロップダウン リストを選択し、[QA] ステージを選択します。

   

7. 使用しているタスクに応じて、設定を変更して、このステージが "QA" ターゲットにデプロイされるようにします。 この例では、次に示すように、[Azure App Service のデプロイ] タスクを使用します。

   

デプロイ前の承認の追加

前に変更したリリース パイプラインは、QA と運用環境にデプロイします。 QA へのデプロイが失敗した場合、運用環境へのデプロイはトリガーされません。 運用環境にデプロイする前に、アプリが QA またはテスト ステージで適切に動作しているかどうかを常に確認することをお勧めします。 承認を追加すると、次のステージにデプロイする前にすべての条件が確実に満たされるようになります。 パイプラインに承認を追加するには、次の手順に従います:

1. [パイプライン] タブの [デプロイ前条件] アイコンを選択し、[デプロイ前承認者] を選択します。

   

2. [承認者] テキスト ボックスに、デプロイの承認を担当するユーザーを入力します。 また、[リリースまたはデプロイを要求しているユーザーは承認しないでください] チェック ボックスのチェックを外すこともお勧めします。

   

   個々のユーザーと組織グループの両方について、必要な数の承認者を追加できます。 パイプライン図のステージの右側にある [ユーザー] アイコンを選択することで、デプロイ後の承認を設定することもできます。 詳細については、ゲートと承認のリリースに関する記事を参照してください。

3. [保存] を選択します。

   

リリースを作成する

リリース パイプラインのセットアップが完了したら、デプロイを開始します。 これを行うには、新しいリリースを手動で作成します。 通常、新しいビルド成果物が使用可能になると、リリースが自動的に作成されます。 ただし、このシナリオでは手動で作成します。

1. [リリース] ドロップダウン リストを選択して、[リリースの作成] を選択します。

   

2. リリースの説明を入力し、正しい成果物が選択されていることを確認してから、[作成] を選択します。

   

3. 新しいリリースが作成されたことを示すバナーが表示されます。 詳細を表示するには、リリース リンクを選択します。

   

4. リリースの概要ページには、各ステージへのデプロイの状態が表示されます。

   

   リリースの一覧など、その他のビューにも、承認待ちであることを示すアイコンが表示されます。 そのアイコンをポイントすると、ステージ名と詳細情報が記載されたポップアップが表示されます。 これにより、管理者が、承認待ちのリリースとすべてのリリースの全体的な進行状況を容易に確認できます。

   

5. [保留中の承認] アイコンを選択して、承認ウィンドウ パネルを開きます。 簡潔なコメントを入力し、[承認] を選択します。

   

注意

ピーク時以外の時間帯など、デプロイを後日にスケジュールできます。 承認を別のユーザーに再割り当てすることもできます。 リリース管理者は、すべての承認決定にアクセスしてオーバーライドできます。

デプロイを監視および追跡する

デプロイ ログは、アプリケーションのリリースを監視およびデバッグするのに役立ちます。 デプロイのログをチェックするには、次の手順に従います:

1. リリースの概要で、ステージにカーソルを合わせ、[ログ] を選択します。

   

   デプロイ中でも、ログ ページにアクセスして、すべてのタスクのライブ ログを確認できます。

2. 任意のタスクを選択すると、その特定のタスクのログが表示されます。 これにより、デプロイの問題のトレースとデバッグが容易になります。 個々のタスク ログ、またはすべてのログ ファイルの zip をダウンロードすることもできます。

   

3. デプロイをデバッグするために追加情報が必要な場合は、デバッグ モードでリリースを実行できます。

次のステップ

承認とゲートを使用してデプロイを制御する