GitHub Actions の概要

  • 7 分

"ワークフロー" を使用して、デプロイ プロセスの各ステップを自動化できます。 コードに変更を加え、その変更を Git リポジトリにコミットするたびに、ワークフローによって定義済みのプロセスが実行されます。 ワークフローでは、Bicep コードが品質基準を満たしているかどうかを確認した後、リソースを Azure にデプロイするアクションを自動化できます。 このプロセスは、ユーザーが作成する "ワークフロー定義" によって定義されます。

GitHub Actions は GitHub の機能です。 GitHub には、コードを格納し、コラボレーターと共有するために使用する Git リポジトリもホストされています。 Bicep コードを GitHub に格納すると、GitHub Actions からそのコードにアクセスし、デプロイ プロセスを自動化できます。 このユニットでは、GitHub Actions について学習します。

ワークフローとは

ワークフローは、コードのテストとデプロイに使用される、ファイル内で定義された構成可能で反復可能なプロセスです。 ワークフローは、正しい順序で並んだ実行する必要があるすべての手順から構成されます。

GitHub Actions を使用する場合は、YAML ファイルでワークフローの構成を定義します。 ワークフロー YAML ファイルはコード ファイルなので、このファイルは Bicep コードと一緒に Git リポジトリ内の .github/workflows という名前のフォルダーに格納されます。 YAML ファイルは構造化テキスト ファイルであり、Bicep 構造化テキスト ファイルに似ています。 YAML ファイルの作成と編集には、任意のテキスト エディターを使用できます。 このモジュールでは、エディターとして Visual Studio Code を使用します。 GitHub Web インターフェイスには、ワークフローの YAML ファイルの表示と編集、ワークフロー定義での共同作業、コミットと分岐を使用したさまざまなバージョンのワークフロー ファイルの管理に使用できるツールが用意されています。

ランナー

これまでは、ローカル コンピューターから Bicep ファイルをデプロイしてきました。 Bicep テンプレートを作成した後は、Azure CLI または Azure PowerShell を使用してこれを Azure にデプロイします。 これらのツールでは、お使いのコンピューターのリソースを使用して Azure にテンプレートを送信します。 お客様の個人の ID を使用して Azure に対する認証が行われ、お客様がリソースをデプロイするアクセス許可を持っていることが確認されます。

また、ワークフローは、デプロイ アクションを実行できるように、適切なオペレーティング システムとハードウェア プラットフォームを持つコンピューターまたは GPU にもアクセスする必要があります。 GitHub Actions では、ワークフローのデプロイの手順を実行するように構成されているコンピューターである "ランナー" が使用されます。 各ランナーには、以前のモジュールで使用した Bicep ツールと Azure ツールが既に備わっています。そのため、ご自分のコンピューターから実行するのと同じ操作を実行できます。 ユーザーがコマンドを実行する代わりに、GitHub Actions サービスによって、ワークフロー YAML ファイルで定義したステップを実行するようランナーに指示が出されます。

GitHub Actions には、Linux や Windows など、さまざまなオペレーティング システム用の複数の種類のランナーと、ツールの各種セットが用意されています。 GitHub によってこれらのランナーが管理されるため、お客様がランナーのコンピューティング インフラストラクチャを管理する必要はありません。 ランナーは、ユーザーに代わってホストされていることから、"GitHub ホステッド ランナー" または "ホステッド ランナー" とも呼ばれます。 ワークフローが実行されると、ホステッド ランナーが自動的に作成されます。 ワークフロー実行が完了すると、ホステッド ランナーは自動的に削除されます。 ホステッド ランナーに直接アクセスすることはできません。そのため、ソリューションをデプロイするために必要なすべてのステップがワークフローに含まれていることが重要です。

Diagram that shows a workflow that runs on a runner.

Note

"セルフホステッド ランナー" と呼ばれるカスタム ランナーを作成することができます。 ワークフローの一部として実行する必要がある特定のソフトウェアがある場合、またはランナーの構成方法を正確に制御する必要がある場合は、セルフホステッド ランナーを作成できます。 このモジュールではセルフホステッド ランナーについて説明しませんが、「まとめ」セクションで詳細情報へのリンクを提供します。

トリガー

GitHub Actions にワークフローを実行する "タイミング" を指示するには、"トリガー" を使用します。 複数の種類のトリガーから選択できます。 ここでは、"手動トリガー" を使用して、ワークフローの実行を開始するタイミングを GitHub Actions に指示します。 他の種類のトリガーについては、このモジュールで後ほど詳しく学習します。

Diagram that shows a trigger initiating a workflow.

手順

"ステップ" は、ワークフローで実行する 1 つの操作を表します。 ステップは、Bash や PowerShell で実行する個々のコマンドに似ています。 ほとんどのデプロイでは、複数のステップをシーケンスで実行します。 ワークフロー YAML ファイルで、シーケンスと、各ステップの全詳細を定義します。

GitHub Actions には、次の 2 種類のステップがあります。

  • 実行ステップ:実行ステップを使用すると、Bash、PowerShell、または Windows コマンド シェルで、1 つのコマンド、またはコマンドのシーケンスを実行できます。
  • アクション ステップ:アクション ステップは、スクリプト ステートメントを記述せずにさまざまな機能にアクセスする便利な方法です。 たとえば、Bicep ファイルを Azure にデプロイする組み込みのタスクがあります。 誰でもアクションを作成し、他のユーザーと共有することができます。 多数の商用およびオープンソースのタスクを使用できます。

一部のユーザーは、アクションの代わりにスクリプト ステートメントを使用することを好みます。実行内容をより細かく制御できるからです。 スクリプトの記述と管理が不要なため、アクションを使用することを好むユーザーもいます。 このモジュールでは、両方のアプローチを組み合わせて使用します。

ジョブ

GitHub Actions の "ジョブ" とは、順序立てられた一連のステップのことです。 ワークフローには常に少なくとも 1 つのジョブがあり、複雑なデプロイを作成するときは、複数のジョブを使用するのが一般的です。

Note

各ジョブを異なるランナーで実行するように設定できます。 異なるランナーでのジョブの実行は、ジョブ ワークフローの異なる部分で異なるオペレーティング システムを使用する必要があるソリューションをビルドしてデプロイする場合に便利です。

たとえば、iOS アプリと、そのアプリのバックエンド サービスをビルドするとします。 macOS ランナーで実行する 1 つのジョブを使用して iOS アプリをビルドし、Ubuntu または Windows ランナーで実行するもう 1 つのジョブを使用してバックエンドをビルドすることができます。 2 つのジョブを同時に実行するようワークフローに指示し、ワークフロー実行を高速化することもできます。

Diagram that shows a workflow with two steps, both within one job.

基本的なワークフローの例

GitHub Actions の基本的な概念がわかったところで、YAML での単純なワークフロー定義を見てみましょう。

name: learn-github-actions

on: [workflow_dispatch]

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
      - name: 'Run a one-line command'
        run: echo "hello from GitHub Actions"
      - name: 'Run a multi-line command'
        run: |
          echo "We'll add more steps soon."
          echo "For example, we'll add our Bicep deployment step."

このファイルの各部分を詳しく見てみましょう。

  • name はワークフローの名前です。 この名前は、GitHub の Web インターフェイスに表示されます。
  • on によって、実行するタイミングをワークフローに指示します。 この場合、on: [workflow_dispatch] を使用して、ワークフローを手動でトリガーするように GitHub Actions に指示しています。
  • jobs によって、ワークフロー内のすべてのジョブをグループ化します。
  • say-hello は、このワークフローで最初の、そして唯一のジョブの名前です。
  • runs-on によって、ジョブの実行時に使用するランナーをワークフローに指示します。 この例では、GitHub ホステッド ランナーのプールから取得された、Ubuntu オペレーティング システム上でワークフローを実行します。
  • steps には、ジョブで実行する各ステップのシーケンスを記載します。 YAML の例には 2 つのステップがあります。 どちらのステップでも、何らかのテキストをエコーするシンプルなスクリプトが実行されます。 各ステップには、人間が読み取り可能な name 値があります。 ワークフロー ログに名前が表示されます。 複数行のスクリプト ステップを作成するには、例に示すようにパイプ文字 (|) を使用します。 ステップが実行されると、ワークフロー ログにその出力が表示されます。

重要

YAML ファイルではインデントが重要になります。 例の YAML を見てみましょう。 この YAML の一部の行は、2 つまたは 4 つのスペースでインデントされています。 ファイルを正しくインデントしないと、GitHub Actions で解釈できません。 Visual Studio Code は、YAML ファイルのインデントの誤りを見つけて修正するのに役立ちます。