演習 - pull request を作成、レビュー、マージする

5 分

Web サイトにキューを追加する作業が完了しました。これで、Web サイト開発チームでは、変更をメインブランチにマージする準備が整いました。この演習では、変更の pull request を作成してマージします。

このプロセスでは、次のことを行います。

pull request を作成します。
pull request をレビューします。
pull request を完了します。
変更がマージされたことを確認します。

機能ブランチをマージする pull request を作成する

リポジトリのメインブランチに変更を直接プッシュすることはできないので、pull request を作成する必要があります。

ブラウザーで [Code](コード) に移動します。
[2 branches](2 ブランチ) を選択して、GitHub リポジトリ内のブランチを一覧表示します。
[add-orders-queue] の横にある [その他] アイコン (...) を選択し、[新しい pull request] を選択します。
pull request を作成した場合、GitHub で Git コミットメッセージが pull request のタイトルとして自動的に使用されていることがわかります。

説明を次のテキストに更新します。

この PR は、注文を処理するための新しい Azure Storage キューを追加し、ストレージアカウントとキュー情報を含めるように Web サイトの構成を更新します。
[pull request の作成] を選択します。

ブラウザーで、[リポジトリ]>[ファイル] に移動します。

Azure DevOps によって、add-orders-queue ブランチに変更があることを示すバナーが表示されているのがわかります。このバナーでは、それらの変更に対する pull request を作成することが提案されます。
[Pull request の作成] を選択します。
pull request を作成するページでは、Azure DevOps によって、Git コミットメッセージが pull request のタイトルとして自動的に使用されていることがわかります。

説明を次のテキストに更新します。

この PR は、注文を処理するための新しい Azure Storage キューを追加し、ストレージアカウントとキュー情報を含めるように Web サイトの構成を更新します。
［作成］ を選択します

pull request をレビューする

通常、pull request は作成者以外の誰かによってレビューされます。この例では、別のチームメンバーのふりをして自分の pull request をレビューしましょう。

pull request ページで、[Files changed] タブを選択します。

GitHub により、この pull request で変更されたファイルが表示されます。変更された行はすべて強調表示されているため、何をレビューする必要があるか簡単に確認できます。

ヒント

自分のチームに対してこれをレビューしていると想像してください。何か提案はありますか?
変更された main.bicep ファイルの 18 行目にカーソルを置き、プラス記号 (+) が付いたボタンを選択します。
コメントボックスに、次のテキストを入力します: 「これは大文字にする必要がありますか?」
[Start a review](レビューの開始) を選択します。

ヒント

GitHub では、自分の pull request を承認することはできません。ここでは、自分の pull request にコメントを付けますが、承認はしません。自分のチームの pull request を操作している場合は、ここで承認を行い、マージしても構わないことを示します。
[Finish your review](レビューの終了) を選択します。
表示されるレビューパネルで、[Submit review](レビューの送信) を選択します。

GitHub によって、pull request の [Conversation](会話) タブに戻ります。

pull request ページで、[Files] タブを選択します。

Azure DevOps により、この pull request で変更されたファイルが表示されます。変更された行はすべて強調表示されているため、何をレビューする必要があるか簡単に確認できます。

ヒント

自分のチームに対してこれをレビューしていると想像してください。何か提案はありますか?
変更された main.bicep ファイルの 18 行目にカーソルを置き、コメントボタンを選択します。
コメントボックスに、次のテキストを入力します: 「これは大文字にする必要がありますか?」
[コメント] を選択します。

ブラウザーウィンドウの幅は、コメントダイアログボックスの表示方法に影響を与える可能性があります。スクリーンショットに示すように、コメントはインラインコメントではなく [Discussion] (ディスカッション) ダイアログボックスを開きます。
[承認] を選択します。

[承認] を選択すると、[オートコンプリートの設定] が [完了] に変わります。この機能は、このレッスンで後ほど使います。

pull request のレビューに応答する

pull request を作成またはレビューする場合は、その内容に関する会話に参加できます。あなたがこのファイルの作成者であり、レビュー担当者からのコメントに応答したい場合を想像してください。

pull request のレビューに対して、次のコメントで応答します: 「いいえ、ストレージキューの名前は小文字にする必要があります。」
[Comment](コメント) を選択し、[Resolve conversation](会話の解決) を選択して、この行に関するディスカッションが終わったことを示します。

pull request ページで、[Overview] (概要) タブを選択します。
ここで、あなたがこのファイルの作成者だとします。 pull request のレビューに対して、次のコメントで応答します: 「いいえ、ストレージキューの名前は小文字にする必要があります。」
[応答して解決] を選択して、この行に関するディスカッションが終わったことを示します。

pull request を完了する

Web サイトの開発チームは、注文をキューに送信する準備ができていることを確認しました。したがって、pull request を完了して統合する準備はできています。

pull request が承認されました。 Web サイトの開発チームは、注文をキューに送信する準備ができていることを確認しました。したがって、pull request を完了して統合する準備はできています。

[Merge pull request](pull request をマージする) を選択します。
GitHub からマージの確認を求めるメッセージが表示されます。 GitHub によって pull request がマージされると、コミットが作成され、コミットメッセージが自動的に生成されます。 [Confirm merge](マージの確認) を選択します。

pull request がマージされ、新しい機能がリポジトリのメインブランチに追加されました。
作業が完了した機能ブランチは、削除することをお勧めします。ブランチを削除すると、進行中の作業がどれなのかについて、今後チームメンバーが混乱せずにすみます。 [Delete branch](ブランチの削除) を選択します。

[Complete](完了) を選択します。
[pull request の完了] で、既定の設定を使用します。 [マージの完了] を選択します。

pull request がマージされ、新しい機能がリポジトリのメインブランチに追加されました。

pull request をマージしたときに、Azure DevOps によって機能ブランチが自動的に削除されました。作業が完了した機能ブランチは、削除することをお勧めします。ブランチを削除すると、進行中の作業がどれなのかについて、今後チームメンバーが混乱せずにすみます。

変更を確認する

pull request をマージした後、変更が正常にマージされたことを確認することをお勧めします。

[Code](コード) に移動します。
deploy/main.bicep ファイルに移動し、次に deploy/modules/appService.bicep ファイルに移動します。

キューと他の変更がファイルに追加されていることがわかります。