ワークフロー ジョブについて
ワークフローを使用すると、デプロイ プロセスのステップを自動化できます。 プロセスには、実行するジョブの論理グループがいくつか含まれる場合があります。 このユニットでは、ワークフロー ジョブについて、およびそれらを使用して Bicep デプロイに品質管理プロセスを追加する方法について学習します。
ワークフロー ジョブとは何ですか?
ジョブは、ワークフローを複数の論理ブロックに分割するのに役立ちます。 各ジョブには、1 つ以上のステップを含めることができます。
ワークフローでジョブを使用すると、関心の分離をマークできます。 たとえば、Bicep コードを操作するとき、コードの検証は Bicep ファイルのデプロイとは別の関心です。 自動化されたワークフローを使用する場合、コードのビルドとテストは、多くの場合、継続的インテグレーション (CI) と呼ばれます。 自動化されたワークフローにコードをデプロイすることは、多くの場合、継続的デプロイ (CD) と呼ばれます。
CI ジョブでは、コードに加えられた変更の有効性を確認します。 CI ジョブでは、品質保証を提供します。 実運用環境に影響を与えずに実行できます。
多くのプログラミング言語では、ユーザーがコードを実行するには、まずコードを "ビルド" する必要があります。 Bicep ファイルがデプロイされると、Bicep から JSON に変換 ("トランスパイル") されます。 ツールでは、このプロセスが自動的に実行されます。 ほとんどの場合、ワークフロー内の JSON テンプレートに Bicep コードを手動でビルドする必要はありません。 ただし、Bicep コードについて説明するときは、継続的インテグレーションという用語を引き続き使用します。コードの検証など、CI の他の部分が引き続き適用されるためです。
CI ジョブが正常に実行されたら、加えた変更も正常にデプロイされるという確信が高まります。 CD ジョブでは、各環境にコードをデプロイします。 通常は、テストおよびその他の非運用環境から開始し、運用環境に移ります。 このモジュールでは、1 つの環境にデプロイします。 今後のモジュールでは、デプロイ ワークフローを拡張して、非運用環境や運用環境などの複数の環境にデプロイする方法について学習します。
既定では、ジョブは並列で実行されます。 各ジョブの実行の方法とタイミングを制御できます。 たとえば、CI ジョブが正常に実行された後にのみ CD ジョブが実行されるように構成できます。 または、コードをビルドしてからテストするなど、シーケンスで実行する必要がある複数の CI ジョブを含める場合があります。 前のデプロイ ジョブが失敗した場合にのみ実行されるロールバック ジョブを含めることもできます。
シフト レフト
ジョブを使用すると、デプロイする前にコードの品質を確認できます。 このプロセスは、"シフト レフト" とも呼ばれます。
コードを記述するときに実行するアクティビティのタイムラインを検討します。 タイムラインは、計画と設計のフェーズから開始します。 その後、ビルドおよびテスト フェーズに移ります。 最後に、ソリューションをデプロイし、サポートする必要があります。
ソフトウェア開発では、プロセスのできるだけ早い段階で (タイムラインのできるだけ左側で) エラーを特定できれば、簡単、迅速、かつ安価にエラーを修正できることがよく知られています。 プロセスでエラーの特定が遅くなるほど、修正がより困難かつ複雑になります。
したがって、問題の検出を上の図の左側にシフトしていくことが目標となります。 このモジュール全体を通して、ワークフローの進行に従って、さらに検証とテストを追加する方法について説明します。
デプロイを開始する前に検証を追加することもできます。 GitHub などのツールを使用する場合、プル要求は通常、チームの一員がメイン ブランチのコードに対して行う変更を表します。 プル要求のレビュー プロセス中に CI ステップを自動的に実行する別のワークフローを作成すると便利です。 この手法は、提案された変更を行っても、コードが引き続き機能することを検証するのに役立ちます。 検証が成功した場合は、変更がメイン ブランチにマージされても問題が発生しないという確信が得られます。 チェックが失敗した場合は、プル要求をマージする準備が整う前に、さらなる作業が必要です。 今後のモジュールでは、プル要求とブランチ戦略を使用して適切なリリース プロセスを設定する方法について詳しく学習します。
重要
自動検証およびテストは、作成したテストと同程度の効果があるにすぎません。 テストする必要のある項目を検討するとともに、デプロイが問題ないという確信を得るために実行する必要のあるステップを検討することが重要です。
ワークフロー ジョブを定義する
すべてのワークフローには少なくとも 1 つのジョブが含まれており、要件に合わせてさらにジョブを定義できます。 既定では、ジョブは並列で実行されます。 所有している GitHub アカウントの種類によって、GitHub ホステッド ランナーを使用するときに同時に実行できるジョブの数が決まります。
2 回 (米国のインフラストラクチャに 1 回、ヨーロッパのインフラストラクチャに 1 回) デプロイする必要がある Bicep ファイルを作成したとします。 ワークフローで Bicep コードを検証することも必要です。 同様のプロセスを定義するマルチジョブ ワークフローの例を以下に示します。
この例には 3 つのジョブがあります。 検証ジョブは CI ジョブに似ています。 次に、米国デプロイ ジョブとヨーロッパ デプロイ ジョブを実行します。 それぞれで、環境のいずれかにコードがデプロイされます。 既定では、ジョブは並行して実行されます。
ワークフロー YAML ファイルでジョブを定義する方法を次に示します。
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deployUS:
runs-on: windows-latest
steps:
- run: echo "Here is where you'd perform the steps to deploy to the US region."
deployEurope:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the steps to deploy to the European region."
ジョブのシーケンスを制御する
ジョブ間に依存関係を追加して、順序を変更できます。 前の例の続きとして、次のようにデプロイ ジョブを実行する前に、コードを検証したいことをよくあります。
ジョブ間の依存関係を指定するには、needs キーワードを使用します。
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deployUS:
runs-on: windows-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy to the US region."
deployEurope:
runs-on: ubuntu-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy to the European region."
needs キーワードを使用すると、ワークフローでは、依存するジョブが正常に完了するまで待機してから、次のジョブが開始されます。 複数のジョブのすべての依存関係が満たされていることがワークフローで検出された場合は、それらのジョブを並列で実行できます。
Note
実際には、複数のジョブを同時に実行するのに十分なランナーがある場合にのみ、ジョブが並列で実行されます。 使用できる GitHub ホステッド ランナーの数は、所有している GitHub アカウントの種類によって異なります。 さらに多くの並列ジョブが必要な場合は、別の GitHub アカウント プランを購入できます。
場合によっては、前のジョブが失敗したときに別のジョブを実行したいこともあります。 たとえば、次のような別のワークフローがあるとします。 デプロイが失敗した場合、そのすぐ後にロールバックというジョブが実行されます。
if キーワードを使用して、ジョブが実行される前に満たされる必要がある条件を指定します。
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deploy:
runs-on: windows-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy."
rollback:
runs-on: ubuntu-latest
needs: deploy
if: ${{ failure() }}
steps:
- run: echo "Here is where you'd perform the steps to roll back a failure."
前の例では、すべて問題がない場合、ワークフローでまずテスト ジョブが実行されてから、デプロイ ジョブが実行されます。 ロールバック ジョブはスキップされます。 しかし、テスト ジョブまたはデプロイ ジョブのいずれかが失敗すると、ワークフローではロールバック ジョブが実行されます。 ロールバックについては、このモジュールで後ほどさらに学習します。
Bicep デプロイ ジョブ
一般的な Bicep デプロイ ワークフローには、いくつかのジョブが含まれています。 ワークフローのジョブが進むにつれて、後続のジョブが成功するという確信が強まるようになることが目標です。 Bicep デプロイ ワークフローの一般的なジョブは次のとおりです。
- リント: Bicep リンターを使用して、Bicep ファイルが整形式であり、明らかなエラーが含まれていないことを確認します。
- 検証: Azure Resource Manager のプレフライト検証プロセスを使用して、デプロイ時に発生する可能性のある問題を確認します。
- プレビュー:what-if コマンドを使用して、Azure 環境に適用される変更の一覧を検証します。 what-if の結果を手動で確認し、ワークフローを承認して続行するように人間に求めます。
- デプロイ: デプロイを Resource Manager に送信して完了するまで待ちます。
- スモーク テスト:デプロイした重要なリソースの一部に対して基本的なデプロイ後チェックを実行します。 これらのチェックは、"インフラストラクチャ スモーク テスト" と呼ばれます。
組織のジョブのシーケンスが異なる場合や、Bicep デプロイを、他のコンポーネントをデプロイするワークフローに統合する必要がある場合があります。 ジョブがどのように動作するのかを理解したら、ニーズに合わせてワークフローを設計することができます。
すべてのジョブは、クリーンな環境から開始される新しいランナー インスタンスで実行されます。 そのため、すべてのジョブでは、通常、最初の手順としてソース コードをチェックアウトする必要があります。 また、Azure と対話するすべてのジョブで、Azure 環境にサインインする必要があります。
このモジュール全体を通して、これらのジョブについて詳しく学習し、各ジョブを含むワークフローを段階的にビルドします。 また、次のことも学習します。
- 前のジョブで予期しないことが発生した場合に、ワークフローによってデプロイ プロセスが停止される方法。
- 前のジョブで何が起こったかを手動で確認するまで一時停止するようにワークフローを構成する方法。