Azure Pipelines を使用した継続的インテグレーションの有効化

受講生用ラボマニュアル

ラボの要件

このラボには、Microsoft Edge または Azure DevOps 対応ブラウザーが必要です。
Azure DevOps 組織を設定する: このラボで使用できる Azure DevOps 組織がまだない場合は、組織またはプロジェクトコレクションの作成に関するページの手順に従って作成してください。

ラボの概要

このラボでは、YAML を使用して Azure DevOps でビルドパイプラインを定義する方法について説明します。このパイプラインは、次の 2 つのシナリオで使用します。

Pull Request 検証プロセスの一部として。
継続的インテグレーションの実装の一部として。

目標

このラボを完了すると、次のことができるようになります。

ビルド検証を Pull Request の一部として含めます。
YAML を使用して CI パイプラインをコードとして構成します。

推定時間:45 分

Instructions

演習 0:ラボの前提条件の構成

この演習では、ラボの前提条件を設定します。これは、eShopOnWeb に基づくリポジトリを含む新しい Azure DevOps プロジェクトで構成されます。

タスク 1: (完了している場合はスキップしてください) チームプロジェクトを作成して構成する

このタスクでは、複数のラボで使用される eShopOnWeb Azure DevOps プロジェクトを作成します。

ラボコンピューターのブラウザーウィンドウで、Azure DevOps 組織を開きます。 [新しいプロジェクト] をクリックします。プロジェクトに「eShopOnWeb」という名前を付け、他のフィールドは既定値のままにします。 [作成] をクリックします。

タスク 2: (完了している場合はスキップしてください) eShopOnWeb Git リポジトリをインポートする

このタスクでは、複数のラボで使用される eShopOnWeb Git リポジトリをインポートします。

ラボコンピューターのブラウザーウィンドウで、Azure DevOps 組織と、前に作成した eShopOnWeb プロジェクトを開きます。 [リポジトリ] > [ファイル] 、 [リポジトリをインポートする] をクリックします。 [インポート] を選択します。 [Git リポジトリをインポートする] ウィンドウで、URL https://github.com/MicrosoftLearning/eShopOnWeb.git を貼り付けて、 [インポート] をクリックします。
リポジトリは次のように編成されています。
- .ado フォルダーには、Azure DevOps の YAML パイプラインが含まれています。
- .devcontainer フォルダーには、コンテナーを使って開発するためのセットアップが含まれています (VS Code でローカルに、または GitHub Codespaces で)。
- infra フォルダーには、一部のラボシナリオで使用される Bicep および ARM のコードとしてのインフラストラクチャテンプレートが含まれています。
- .github フォルダーには、YAML GitHub ワークフローの定義が含まれています。
- src フォルダーには、ラボシナリオで使用される .NET Web サイトが含まれています。

演習 1: ビルド検証を pull request の一部として含める

この演習では、pull request を検証するためのビルド検証を組み込みます。

タスク 1: YAML ビルド定義をインポートする

このタスクでは、pull request を検証するためにブランチポリシーとして使われる YAML ビルド定義をインポートします。

まず、eshoponweb-ci-pr.yml というビルドパイプラインをインポートします。

[パイプライン] > [パイプライン] に移動します
[パイプラインの作成] または [新しいパイプライン] ボタンをクリックします
[Azure Repos Git (YAML)] を選びます
eShopOnWeb リポジトリを選びます
[既存の Azure Pipelines の YAML ファイル] を選択します
メイン ブランチと /.ado/eshoponweb-ci-pr.yml ファイルを選択し、[続行] をクリックします

ビルドの定義は以下のタスクで構成されます。
- DotNet Restore: NuGet パッケージの復元を使うと、ソース管理に格納しなくても、プロジェクトのすべての依存関係をインストールできます。
- DotNet Build: プロジェクトとそのすべての依存関係をビルドします。
- DotNet Test: 単体テストの実行に使われる .Net テストドライバー。
- DotNet Publish: ホスティングシステムへのデプロイ用のフォルダーに、アプリケーションとその依存関係を発行します。この場合は、Build.ArtifactStagingDirectory です。
[保存] ボタンをクリックして、パイプラインの定義を保存します。
パイプラインには、プロジェクト名に基づく名前が付けられます。パイプラインを識別しやすくするために、名前を変更しましょう。 [パイプライン] > [パイプライン] に移動し、先ほど作成したパイプラインをクリックします。省略記号と [名前の変更または移動] オプションをクリックします。それに eshoponweb-ci-pr という名前を付けて、 [保存] をクリックします。

タスク 2: ブランチポリシー

このタスクでは、メインブランチにポリシーを追加し、定義されているポリシーに準拠する pull request を使った変更のみを許可します。ブランチの変更を確認してから、マージする必要があります。

[リポジトリ] > [ブランチ] セクションに移動します。
[ブランチ] ペインの [マイニング] タブで、main ブランチエントリにマウスポインターを合わせると、右側に省略記号が表示されます。
省略記号をクリックし、ポップアップメニューで [ブランチポリシー] を選びます。
リポジトリ設定の [main] タブで、 [Require minimum number of reviewers] (レビュー担当者の最小数を必須にする) のオプションを有効にします。 1 人のレビュー担当者を追加し、 [Allow requestors to approve their own changes] (要求者が自分の変更を承認することを許可する) チェックボックスをオンにします (このラボのプロジェクトでは、自分が唯一のユーザーであるため)
リポジトリ設定の main のタブの [ビルド検証] セクションで、 [+] (新しいビルドポリシーの追加) をクリックし、 [ビルドパイプライン] の一覧で eshoponweb-ci-pr を選んで、 [保存] をクリックします。

タスク 3: pull request を操作する

このタスクでは、Azure DevOps ポータルを使い、保護された main ブランチに変更をマージする新しいブランチを使って、pull request を作成します。

eShopOnWeb のナビゲーションで [リポジトリ] セクションに移動し、 [ブランチ] をクリックします。
main ブランチに基づいて Feature01 という名前の新しいブランチを作成します。
Feature01 をクリックし、Feature01 ブランチの一部として /eShopOnWeb/src/Web/Program.cs ファイルに移動します
右上の [編集] ボタンをクリックします
1 行目を次のように変更します。
```
 // Testing my PR
```
[コミット] > [コミット] をクリックします (既定のコミットメッセージのままにします)。
メッセージがポップアップ表示され、pull request を作成するように提案されます (Feature01 ブランチは main と比較して変更が進んでいるため)。 [Pull request の作成] をクリックします。
[新しい Pull Request] タブで、既定のまま [作成] をクリックします。
pull request では、ターゲットの main ブランチに適用されているポリシーに基づいて、保留中の要求がいくつか示されます。
- 少なくとも 1 人のユーザーが変更を確認し、承認する必要があります。
- ビルド検証では、ビルド eshoponweb-ci-pr が自動的にトリガーされたことがわかります
すべての検証が成功したら、右上の [承認] をクリックします。これで、 [オートコンプリートの設定] ドロップダウンから、 [完了] をクリックできます。
[Pull Request の完了] タブで、 [マージの完了] をクリックします

演習 2: YAML を使用して CI パイプラインをコードとして構成する

この演習では、YAML を使って CI パイプラインをコードとして構成します。

タスク 1: CI 用の YAML ビルド定義をインポートする

このタスクでは、継続的インテグレーションの実装に使う YAML ビルド定義を追加します。

まず、eshoponweb-ci.yml という CI パイプラインをインポートします。

[パイプライン] > [パイプライン] に移動します。
[新しいパイプライン] ボタンをクリックします。
[Azure Repos Git (YAML)] を選びます。
eShopOnWeb リポジトリを選びます。
[既存の Azure Pipelines YAML ファイル] を選びます。
メイン ブランチと /.ado/eshoponweb-ci.yml ファイルを選択し、[続行] をクリックします。

CI の定義は以下のタスクで構成されます。
- DotNet Restore: NuGet パッケージの復元を使うと、ソース管理に格納しなくても、プロジェクトのすべての依存関係をインストールできます。
- DotNet Build: プロジェクトとそのすべての依存関係をビルドします。
- DotNet Test: 単体テストの実行に使われる .Net テストドライバー。
- DotNet Publish: ホスティングシステムへのデプロイ用のフォルダーに、アプリケーションとその依存関係を発行します。この場合は、Build.ArtifactStagingDirectory です。
- 成果物の発行 - Web サイト: (前のステップで作成した) アプリ成果物を発行し、パイプライン成果物として利用できるようにします。
- 成果物の発行 - Bicep: インフラストラクチャ成果物 (Bicep ファイル) を発行し、パイプライン成果物として利用できるようにします。

タスク 2: 継続的インテグレーションを有効にする

既定のビルドパイプライン定義では、継続的インテグレーションは有効になりません。

右上の [編集] ボタンをクリックします
次に、 # trigger: と # - main を次のコードに置き換える必要があります。
```
 trigger:
   branches:
     include:
     - main
   paths:
     include:
     - src/web/*
```
これにより、メインブランチと Web アプリケーションコード (src/web フォルダー) が変更された場合、ビルドパイプラインが自動的にトリガーされます。

ブランチポリシーを有効にしたので、コードを更新するには pull request を渡す必要があります。
[保存] ボタン ( [保存して実行] ではなく) をクリックして、パイプライン定義を保存します。
[このコミットのブランチを新規作成] を選びます。
既定のブランチ名と、オンにされた [pull request の開始] をそのままにして。
[Save] をクリックします。
パイプラインには、プロジェクト名に基づく名前が付けられます。パイプラインを識別しやすくするために、名前を変更しましょう。 [パイプライン] > [パイプライン] に移動し、先ほど作成したパイプラインをクリックします。省略記号と [名前の変更または移動] オプションをクリックします。 eshoponweb-ci という名前を付け、 [保存] をクリックします。
[リポジトリ] > [pull request] に移動します。
“Update eshoponweb-ci.yml for Azure Pipelines” pull request をクリックします。
すべての検証が成功したら、右上の [承認] をクリックします。これで [完了] をクリックできます。
[Pull Request の完了] タブで、 [マージの完了] をクリックします

タスク 3: CI パイプラインをテストする

このタスクでは、pull request を作成し、新しいブランチを使って保護された main ブランチに変更をマージして、CI パイプラインを自動的にトリガーします。

[リポジトリ] セクションに移動します。
main ブランチに基づいて Feature02 という名前の新しいブランチを作成します。
新しい Feature02 ブランチをクリックします。
/eShopOnWeb/src/Web/Program.cs ファイルに移動し、右上の [編集] をクリックします。
1 行目を削除します。
```
 // Testing my PR
```
[コミット] > [コミット] をクリックします (既定のコミットメッセージのままにします)。
メッセージがポップアップ表示され、pull request を作成するように提案されます (Feature02 ブランチは main と比較して変更が進んでいるため)。
[Pull request の作成] をクリックします。
[新しい Pull Request] タブで、既定のまま [作成] をクリックします。
pull request では、ターゲットの main ブランチに適用されているポリシーに基づいて、保留中の要求がいくつか示されます。
すべての検証が成功したら、右上の [承認] をクリックします。これで、 [オートコンプリートの設定] ドロップダウンから、 [完了] をクリックできます。
[Pull Request の完了] タブで、 [マージの完了] をクリックします
[パイプライン] > [パイプライン] に戻ると、コードがマージされた後でビルド eshoponweb-ci が自動的にトリガーされたことがわかります。
eshoponweb-ci ビルドをクリックしてから、最後の実行を選びます。
正常に実行されたら、 [関連] > [発行済み] をクリックして、発行された成果物を調べます。
- Bicep: インフラストラクチャ成果物。
- Web サイト: アプリ成果物。

確認

このラボでは、ビルド定義を使って pull request の検証を有効にし、Azure DevOps で YAML を使って CI パイプラインをコードとして構成しました。