はじめに
Bicep コードを操作するとき、すべての変更を確認してテストすることが重要です。 バグや問題が検出されるようにデプロイのワークフローとプロセスが設計されている場合でも、可能な限り早く問題を見つけ、修正する方が時間がかかりません。 pull request からは、コード変更を確認する機会が与えられます。 Azure のデプロイを確認する場合は、コードの変更を検証するだけでなく、変更が正常にデプロイされ、期待したとおりに機能するかどうかを確認することをお勧めします。
このモジュールでは、pull request レビュー プロセスに自動チェックを追加する方法を学習します。 実際の環境にマージまたはデプロイする前に、pull request 内で Bicep コードに対する変更を検証する方法について学習します。
また、変更を "短期環境" に自動的にデプロイする方法も学習します。これは、コラボレーターとレビュー担当者が、コードが承認されてリポジトリのメイン ブランチにマージされる前に、変更をテストできる一時的な環境です。
シナリオ例
あなたは玩具会社の Azure 管理者だとします。 あなたは Web サイト チームと連携して、Web サイト用に Azure リソースをデプロイして構成する Bicep テンプレートを作成しています。
チームは成長し続けているため、全員が行うすべての変更を管理することがますます難しくなっています。 あなたのプロジェクトの GitHub リポジトリのメイン ブランチに変更がマージされる前に確実にレビューされるように、最近、pull request を使用し始めました。 各レビュー担当者は pull request で Bicep コードの変更を検証し、多くのレビュー担当者は変更を一時的な環境にデプロイして試用することもできます。
あなたは、同僚から、現在の手動レビュー プロセスは面倒で時間がかかると言われました。 チームの全員が pull request レビューを簡単に行えるので、あなたは、pull request 内のレビュー プロセスの一部を自動化することに決めました。
Web サイトの構成を変更する必要があるので、今が新しいプロセスを確立して試すには最適の機会です。
学習内容
このモジュールでは、各 pull request の自動チェックとテストを実行して、Bicep コードの変更に対する信頼度を確立する方法について学習します。
Bicep リンターを使用して推奨プラクティスに対して Bicep コードをスキャンする pull request ワークフローを構成します。 また、各 pull request に短期環境の作成を構成します。これは、Azure 環境への変更を確認し、pull request がマージまたは閉じられるときに環境を自動的に削除するために使用できます。
主な目標
このモジュールを完了すると、Bicep コードに対する GitHub の pull requests に自動チェックと検証を追加できるようになります。