GitHub Actions について
ワークフローを使用して、デプロイ プロセスの手順を自動化できます。 コードに変更を加えて Git リポジトリに変更をコミットするたびに、ワークフローによって定義済みのプロセスが実行されます。 ワークフローでは、Bicep コードが品質基準を満たしているかどうかを確認し、リソースを Azure にデプロイするためのアクションを自動化できます。 プロセスは、作成する ワークフロー定義で定義 されます。
GitHub Actions は GitHub の機能です。 GitHub では、コードを保存してコラボレーターと共有するために使用する Git リポジトリもホストされます。 GitHub に Bicep コードを格納すると、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 ホストランナーまたは ホストランナー と呼ばれることもあります。 ワークフローを実行すると、ホストされたランナーが自動的に作成されます。 ワークフローの実行が完了すると、ホストされているランナーが自動的に削除されます。 ホストされているランナーに直接アクセスすることはできません。そのため、ソリューションのデプロイに必要なすべての手順がワークフローに含まれていることが重要です。
注
カスタム ランナーであるセルフホステッド ランナーを作成できます。 ワークフローの一部として実行する必要がある特定のソフトウェアがある場合、またはランナーの構成方法を正確に制御する必要がある場合は、セルフホステッド ランナーを作成できます。 このモジュールではセルフホステッド ランナーについては説明しませんが、「概要」セクションの詳細情報へのリンクを提供します。
トリガー (条件や動作を引き起こすもの)
トリガーを使用して、ワークフローを実行するタイミングを GitHub Actions に指示します。 複数の種類のトリガーから選択できます。 ここでは、 手動トリガー を使用して、ワークフローの実行を開始するタイミングを GitHub Actions に指示します。 他の種類のトリガーについては、このモジュールで後ほど詳しく学習します。
ステップス
ステップは、ワークフローが実行する 1 つの操作を表します。 ステップは、Bash や PowerShell で実行する個々のコマンドに似ています。 ほとんどのデプロイでは、複数のステップをシーケンスで実行します。 ワークフロー YAML ファイルでは、各ステップのシーケンスとすべての詳細を定義します。
GitHub Actions には、次の 2 種類の手順があります。
- 実行手順: 実行ステップを使用して、Bash、PowerShell、または Windows コマンド シェルで 1 つのコマンドまたは一連のコマンドを実行できます。
- アクション ステップ: アクション ステップは、スクリプト ステートメントを記述せずにさまざまな機能にアクセスする便利な方法です。 たとえば、Bicep ファイルを Azure にデプロイする組み込みタスクがあります。 誰でもアクションを記述し、他のユーザーと共有できます。 多数の商用およびオープンソースのタスクを使用できます。
一部のユーザーは、実行内容をより詳細に制御できるため、アクションの代わりにスクリプト ステートメントを使用することを好みます。 他のユーザーは、スクリプトを記述して管理する必要がないようにアクションを使用することを好みます。 このモジュールでは、両方のアプローチを組み合わせ使用します。
仕事
GitHub Actions では、 ジョブ は順序付けられた一連のステップを表します。 ワークフローには常に少なくとも 1 つのジョブがあり、複雑なデプロイを作成するときに複数のジョブを使用するのが一般的です。
注
各ジョブを別のランナーで実行するように設定できます。 異なるランナーでジョブを実行することは、ジョブ ワークフローのさまざまな部分で異なるオペレーティング システムを使用する必要があるソリューションをビルドして展開する場合に便利です。
たとえば、iOS アプリと、そのアプリのバックエンド サービスをビルドするとします。 iOS アプリをビルドするために macOS ランナーで実行されるジョブと、Ubuntu または Windows ランナーで実行してバックエンドを構築する別のジョブがある場合があります。 2 つのジョブを同時に実行するようにワークフローに指示しても、ワークフローの実行速度が上がります。
基本的なワークフローの例
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 ファイルのインデントの誤りを見つけて修正するのに役立ちます。