pull request の検証について理解する
pull request を使用する場合、Azure デプロイに対するすべての更新が別のユーザーによってレビューされていることを確かめることができます。 しかし、多くの場合、コード変更に対する自動 ''チェック'' の実行も役立ちます。 このユニットでは、コード変更に対するチームの信頼度を高めるために、自動 pull request 検証とチェックをどのように使用できるかについて学習します。
pull request の検証
Bicep コードの pull request をレビューするときに、変更を評価するための一般的な手順がいくつかある場合があります。 これらの手順には以下が含まれます。
- Bicep ファイルにエラーやリンター警告が含まれているかどうかを確認する。
- Bicep ファイルで以前に定義されたリソースが引き続き動作することを確かめる。
- 新しく定義されたリソースをテストし、正常にデプロイされており、期待どおりに動作することを確かめる。
''pull request 検証'' では、これらのアクティビティの一部を自動化する必要があります。 pull request チェックを自動化すると、コードがチームの品質基準を満たしており、ビジネス目標を達成していることを確かめるなど、レビュー担当者は他の重要なレビュー手順に時間をかけることができます。
GitHub Actions ワークフローでは、pull request の作成、更新、マージ、終了時など、pull request プロセス中の特定の時点でワークフローを呼び出すトリガーを定義できます。
pull request 検証ワークフローで Bicep コードをテストする
前のモジュールでは、複数の環境全体を含め、Azure インフラストラクチャの変更をリント、検証、デプロイ、およびテストするための包括的な GitHub Actions ワークフローを構築する方法について学習しました。 これらのワークフローは、変更がメイン ブランチにマージされた後に実行されます。
また、pull request 検証ワークフローの同じアクティビティの多くを実行することもできます。 次に例を示します。
- Bicep コードのリンティングは、コードが意味的に正しく、ベースラインで推奨される Bicep プラクティスに従っていることを確かめるのに役立ちます。
- プレフライト検証は、実際にファイルをデプロイする必要なく、コードが正常にデプロイされるという自信を持てるようにします。 リソースの種類によっては、プレフライト検証で、無効なリソース名、特定のリソースの無効なリージョン、および正常にデプロイできない構成を指定したかどうかなどの問題が見つかる場合があります。
- what-if。デプロイの結果として Azure 環境に加えられる変更を一覧表示します。
- デプロイ。実際にリソースをデプロイし、デプロイ エラーが発生していないことを確かめます。
- デプロイ後にリソースをテストし、ビジネス要件に従って構成されていることを確かめます。
pull request 検証ワークフローは通常の GitHub Actions ワークフローであるため、これらのどのタスクも実行できます。 しかし、pull request 内で実行するのに適したチェックの種類について考えてみる価値があります。 ここに一覧表示されている検証アクティビティの多くには Azure 環境へのアクセスが必要です。 たとえば、what-if 操作では、Bicep ファイルで定義されているリソースと Azure サブスクリプションのリソースが比較されます。 この比較を運用環境に対して実行するのが適切です。 しかし、追加のリスクが発生するため、まだ完了もマージもしていないコード用に設計されたワークフローの運用環境に対しては操作を実行したくない場合があります。
このモジュールでは、pull request 検証ワークフローに次の 2 種類のチェックを追加します。
- Bicep コードをリンティングして、それに対して最初のチェック セットを実行する。
- 新しい一時的な環境にコードをデプロイする。
これら 2 つのアクティビティでは、Azure の運用環境に接続したり、テスト、QA、ステージングなどの通常の非運用環境に接続したりする必要はありません。 これら 2 つのアクティビティを実行することで、コード変更に対するかなりの信頼度を高め、リポジトリのメイン ブランチにマージすることができます。
チェックは、アクティビティの手動実行に費やされる時間を節約できるため、レビュー担当者にとって役立ちます。 このチェックはデプロイ プロセスの後半で変更がどのように機能するかを最初に把握する手段として使用できるため、pull request 作成者にとっても便利です。
独自の pull request 検証ワークフローでは、アクティビティを追加して検証チェックを拡張することができます。
pull request ライフサイクル トリガー
GitHub の pull request はさまざまな ''ライフサイクル イベント'' を通過する可能性があります。 たとえば、1 つの pull request が ''開かれた'' とします。 その後、作成者はソース ブランチに変更をプッシュする (''同期する'') 可能性があります。これは、pull request の内容に影響します。 その後、pull request を ''マージ'' できます。またはマージせずに ''終了'' し、後で ''再度開く'' こともできます。
GitHub Actions を利用すれば、これらのイベントのいずかに応答する ''ワークフロー トリガー'' を定義できます。 たとえば、追加構成なしで pull_request トリガーを指定すると、pull request が開かれるか、同期されるか、あるいは再度開かれるたびに自動的に実行されるワークフローを定義できます。
on: pull_request
また、ワークフローをトリガーする pull request イベントを指定することもできます。 たとえば、次のワークフローは、pull request が終了するたびに自動的に実行されます。
on:
pull_request:
types: [closed]
重要
pull request でマージ競合が発生した場合、ワークフローは実行されません。 ワークフローを実行できるように、競合を解決し、解決策をプッシュする必要があります。
pull request の状態チェック
pull request ワークフローの結果は、''チェック'' として pull request の詳細ページに表示されます。 チェックを使用すると、作成者とレビュー担当者は、次の例に示すように、自動化されたアクティビティが成功または失敗したかどうかに関するフィードバックをすばやく得ることができます。
既定では、チェックが失敗した場合でも、pull request をマージできます。 これを許可したくない場合もあるため、''ブランチ保護規則'' を構成し、pull request をマージする前に特定のチェックが成功する必要があることを強制できます。
ファイルの更新
pull request が作成された後、作成者が更新を行う必要があるのが一般的です。 次に例を示します。
- レビュー担当者は作成者にコードの変更を求める場合があります。
- 自動チェックが失敗した場合、作成者はコードを変更して問題を解決してから、変更をコミットしてプッシュできます。
pull_request トリガーを使用することで、ソース ブランチが更新されるごとに実行するように検証ワークフローを構成できます。 ワークフローの最新の実行結果は、pull request の詳細ページに表示されます。
再利用可能なワークフロー
pull request 検証の可能なチェックのリストを見ると、これらが通常のデプロイ ワークフローで実行されるのと同じ手順であることがわかります。 繰り返しを回避するために、GitHub の ''再利用可能なワークフロー'' を使用することをお勧めします。
さまざまなワークフロー定義で使用するジョブごとに再利用可能なワークフローを定義できます。 この方法については、次の演習で説明します。
ドラフト プル リクエスト
通常、作成者は、変更をレビュー、承認、マージする準備ができたら pull request を開きます。 しかし、変更をマージする準備がまだできていなくても、コードを記述するプロセス全体を通して、自動 pull request 検証チェックにアクセスできると便利な場合があります。
GitHub で pull request を開くときに、''ドラフト'' としてマークできます。 GitHub は同じ自動チェックをすべて実行し、レビュー担当者は引き続きフィードバックを提供できます。 ただし、pull request がドラフト状態になると、作業がまだ完全なレビューの準備ができていないので、マージできないことは誰の目にも明らかです。
特に pull request 検証ワークフローで一時的な環境が作成される場合は、ドラフト pull request を作成するのが一般的です。これは、ライブの作業環境で変更をプレビューできるためです。 変更をプッシュし続けると、一時的な環境が更新されて最新の変更が組み込まれます。