Bicep の変更をレビューしてマージする
機能ブランチを使う方法と、ブランチ保護を適用して、変更がマージされる前にレビューされるようにする方法について学習しました。 次に、一貫したプロセスに従って、変更をマージする前に提案してレビューする必要があります。
このユニットでは、pull request について、その作成方法や使用方法などをさらに詳しく学習します。 また、pull request を使って Bicep コードをレビューする方法も学習します。
Pull Request
pull request は、機能の開発者からメイン ブランチの保守管理者への "要求" です。 開発者は、保守管理者に、リポジトリのメイン ブランチに変更を "プル" するよう依頼します。
pull request とブランチ保護
ブランチ保護を構成する場合は、コードの所有者に pull request をレビューするよう要求することができます。 たとえば、あるユーザーのすべての pull request のレビュー担当者としてプロジェクト リードを含めたり、または一定数の人々がすべての pull request をレビューする必要があることを指定したりする場合があります。
pull request とブランチ ポリシー
ブランチ ポリシーを構成する場合、特定の人や人々のグループに pull request をレビューするよう要求できます。 たとえば、あるユーザーのすべての pull request のレビュー担当者としてプロジェクト リードを含めたり、または一定数の人々がすべての pull request をレビューする必要があることを指定したりする場合があります。
また、各 pull request が作業項目にリンクされるように要求することもできます。 この構成を使うと、機能要求を含む作業項目から、その変更を実装するコードまで、運用環境にデプロイするまでの全作業を追跡できます。
pull request を作成する
GitHub の Web インターフェイスを使って pull request を作成できます。 変更を行ったソース ブランチと、通常はリポジトリのメイン ブランチであるターゲット ブランチを選択します。
Azure DevOps の Web インターフェイスを使って pull request を作成できます。 変更を行ったソース ブランチと、通常はリポジトリのメイン ブランチであるターゲット ブランチを選択します。
pull request を作成する際は、名前を指定する必要があります。 pull request には明確でわかりやすい名前を付けることをお勧めします。 これにより、チーム メンバーがレビューを求められていることの文脈を理解しやすくなります。 メンバーがさまざまな分野の専門知識を持っている場合は、適切な名前によって、メンバーが有意義なフィードバックを提供できる pull request を見つけたり、関連性の低い pull request をスキップしたりすることができます。
pull request 名は Git リポジトリの履歴の一部になることが多いため、誰かがその履歴を振り返った際に理解できるようにすることをお勧めします。
pull request に説明を指定することもできます。 説明内で、特定の人々に言及したり、問題を参照したりすることができます。 多くのチームでは、各変更が何であるかを明確にするために、pull request の説明用に標準化されたテンプレートを作成しています。
pull request に説明を指定することもできます。 説明の中で特定の人々にメンションしたり、作業項目を参照したりすることができます。 多くのチームでは、各変更が何であるかを明確にするために、pull request の説明用に標準化されたテンプレートを作成しています。
pull request を作成するときに、変更をレビューする人を招待できます。
場合によっては、同僚からフィードバックを得るためだけに pull request を作成することがあります。 このような状況では、pull request が "ドラフト" であることを指定できます。 レビュー担当者には、変更がまだ作業中であることがわかります。 それでもレビュー担当者はフィードバックを提供できますが、変更をマージする準備はまだできていないことが明確になります。 変更に問題がなければ、ドラフトの状態を削除できます。
pull request を作成した後でも、機能ブランチ上でコードに変更を加え続けることができます。 これらの変更は、pull request の一部になります。
pull request をレビューする
pull request をレビューすると、すべての変更を簡単に確認できます。 pull request 全体に対してコメントする、または変更されたファイルの特定の部分に対してコメントすることができます。 pull request の作成者はコメントに応答でき、他のレビュー担当者はディスカッションに参加できます。 これらのコメント機能により、pull request でのコラボレーションが対話型のエクスペリエンスになります。
Bicep コードをレビューする際は、次の重要な要素を調べます。
- ファイルはデプロイ可能ですか。 マージする前に、Bicep コードをデプロイしてテストします。 リンターの警告が発生しないことと、Azure のデプロイが成功することを確認します。 今後の Microsoft Learn モジュールで、変更を自動的にデプロイして検証する方法について学習します。
- Bicep コードは明確でわかりやすいですか。 チームの誰もが Bicep コードを理解することが重要です。 pull request で Bicep ファイルをレビューするときは、すべての変更の意味を正確に理解する必要があります。 変数とパラメーターの名前は適切ですか。 コードの複雑なセクションを説明するためにコメントが使用されていますか。
- 変更は完了していますか。 この pull request がより広範な作業の一部を表している場合は、この変更がマージされてデプロイされたときに環境が動作することを確認してください。 たとえば、pull request によって後の変更に備えて Azure リソースが再構成される場合は、プロセス全体でリソースが引き続き正常に動作することを確認します。 pull request によってまだ必要ない新しい Azure リソースが追加される場合は、必要になるまでリソースがデプロイされないようにするために、条件を一時的に追加する必要があるかどうかを検討します。
- 変更は優れた Bicep のプラクティスに従っていますか。 他の Microsoft Learn モジュールで、優れた Bicep コードの要素について学習しました。 レビューするコードが、それらと同じベスト プラクティスに従っていることを確認してください。
- 変更は説明と一致していますか。 pull request にはわかりやすいタイトルを含めることをお勧めします。 多くのチームでは、変更とその目的の説明を pull request に含めることも求められます。 Bicep コードに対する変更が、pull request の詳細と一致することを確認します。 pull request の作成者が作業項目や問題にリンクしている場合は、pull request 内の変更が、作業項目によって定義されている成功基準を満たしていることを確認してください。
pull request を完了する
pull request は、承認した後、"完了" することができます。 これは、pull request の内容がメイン ブランチにマージされることを意味します。
あるチームでは、pull request の作成者がその完了も行う必要があります。 このプロセスは、マージが発生するタイミングを作成者が制御するのに役立ち、自動化されたデプロイを監視するために利用できます。 承認者が pull request を完了するチームもあります。 お客様のチームで、誰が、いつ pull request をマージするかを決定する必要があります。
あるチームでは、pull request の作成者がその完了も行う必要があります。 このプロセスは、マージが発生するタイミングを作成者が制御するのに役立ち、自動化されたデプロイを監視するために利用できます。 承認者が pull request を完了するチームもあります。 Azure DevOps を使って、承認基準を満たす場合に pull request を自動的に完了することもできます。 お客様のチームで、誰が、いつ pull request をマージするかを決定する必要があります。
チームのプロセス
機能ブランチと pull request の使用を開始すると、チームのプロセスが次のように変わる場合があります。
チーム メンバーは、共有されているリポジトリを複製します。
メンバーは、ローカルにコピーした自分専用のリポジトリ内のブランチでローカルの変更を行います。
変更が完了したら、ローカル ブランチを共有リポジトリにプッシュします。
共有リポジトリ内で、ブランチを main にマージする pull request を作成します。
他のチーム メンバーは変更をレビューします。 問題がなければ、pull request は承認され、共有リポジトリのメイン ブランチにマージされます。
共有リポジトリとそのリポジトリの自分のローカル コピー内のブランチを削除します。
一部のシナリオでは、リモート リポジトリへのプッシュによって、自動化されたパイプラインがトリガーされ、コードの検証、テスト、デプロイが行われます。 パイプラインについては、他の Microsoft Learn モジュールを参照してください。
次の図は、この修正されたプロセスを示しています。
