ワークフロージョブについて

7 分

ワークフローを使用すると、デプロイプロセスのステップを自動化できます。プロセスには、実行するジョブの論理グループがいくつか含まれる場合があります。このユニットでは、ワークフロージョブについて、およびそれらを使用して Bicep デプロイに品質管理プロセスを追加する方法について学習します。

ワークフロージョブとは何ですか?

ジョブは、ワークフローを複数の論理ブロックに分割するのに役立ちます。各ジョブには、1 つ以上のステップを含めることができます。

1 つのジョブが含まれるワークフローを示す図。ジョブには、4 つのステップが含まれています。

ワークフローでジョブを使用すると、関心の分離をマークできます。たとえば、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."

ジョブのシーケンスを制御する

ジョブ間に依存関係を追加して、順序を変更できます。前の例の続きとして、次のようにデプロイジョブを実行する前に、コードを検証したいことをよくあります。

ワークフローに検証ジョブと、並列で実行する 2 つのデプロイジョブつまり米国デプロイジョブとヨーロッパデプロイジョブが含まれることを示す図。

ジョブ間の依存関係を指定するには、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 アカウントプランを購入できます。

場合によっては、前のジョブが失敗したときに別のジョブを実行したいこともあります。たとえば、次のような別のワークフローがあるとします。デプロイが失敗した場合、そのすぐ後にロールバックというジョブが実行されます。

1 つのデプロイジョブと、デプロイジョブが失敗したときにロールバックジョブを実行するという条件が含まれるワークフローを示す図。

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 デプロイワークフローの一般的なジョブは次のとおりです。

リント、検証、プレビュー、デプロイ、スモークテストという 5 つのジョブを含む Bicep デプロイワークフローを示す図。

リント: Bicep リンターを使用して、Bicep ファイルが整形式であり、明らかなエラーが含まれていないことを確認します。
検証: Azure Resource Manager のプレフライト検証プロセスを使用して、デプロイ時に発生する可能性のある問題を確認します。
プレビュー:what-if コマンドを使用して、Azure 環境に適用される変更の一覧を検証します。 what-if の結果を手動で確認し、ワークフローを承認して続行するように人間に求めます。
デプロイ: デプロイを Resource Manager に送信して完了するまで待ちます。
スモークテスト:デプロイした重要なリソースの一部に対して基本的なデプロイ後チェックを実行します。これらのチェックは、"インフラストラクチャスモークテスト" と呼ばれます。

組織のジョブのシーケンスが異なる場合や、Bicep デプロイを、他のコンポーネントをデプロイするワークフローに統合する必要がある場合があります。ジョブがどのように動作するのかを理解したら、ニーズに合わせてワークフローを設計することができます。

すべてのジョブは、クリーンな環境から開始される新しいランナーインスタンスで実行されます。そのため、すべてのジョブでは、通常、最初の手順としてソースコードをチェックアウトする必要があります。また、Azure と対話するすべてのジョブで、Azure 環境にサインインする必要があります。

このモジュール全体を通して、これらのジョブについて詳しく学習し、各ジョブを含むワークフローを段階的にビルドします。また、次のことも学習します。

前のジョブで予期しないことが発生した場合に、ワークフローによってデプロイプロセスが停止される方法。
前のジョブで何が起こったかを手動で確認するまで一時停止するようにワークフローを構成する方法。

ワークフロー ジョブについて

ワークフロー ジョブとは何ですか?

シフト レフト

ワークフロー ジョブを定義する