GitHub Actionsの使い方の流れ

1. はじめに

開発チームの生産性を向上させるために、CI/CDパイプラインの構築は今や必須となっています。GitHub Actionsは、GitHubのリポジトリに直接統合された自動化プラットフォームとして、ビルド、テスト、デプロイメントのすべてを一元管理できます。

本記事では、GitHub Actionsの仕組みと実践的な活用方法について、技術的な観点から解説します。

2. GitHub Actionsとは

GitHub Actionsは、継続的インテグレーション（CI）と継続的デリバリー（CD）を実現するプラットフォームです。リポジトリ内でイベントが発生したときに自動的にワークフローを実行し、コードのビルド、テスト、デプロイメントを自動化できます。

従来のCI/CDツールと異なり、GitHubのエコシステムに完全に統合されているため、外部サービスとの連携設定が不要で、すぐに利用を開始できます。また、DevOpsの範囲を超えて、Issueの自動ラベル付けなど、リポジトリで発生する様々なイベントに対応したワークフローを実行できます。

GitHubは、Linux、Windows、macOSの仮想マシンを提供しており、セルフホストランナーを使用して独自のインフラでワークフローを実行することも可能です。

3. アーキテクチャの理解

GitHub Actionsは、以下の5つの主要コンポーネントで構成されています。

3.1. ワークフロー（Workflows）

ワークフローは、.github/workflowsディレクトリに配置されたYAMLファイルで定義される、1つ以上のジョブを実行する自動化プロセスです。リポジトリ内のイベント、手動実行、または定期スケジュールによってトリガーされます。

リポジトリには複数のワークフローを配置でき、それぞれが異なる目的を持つことができます。

• プルリクエストのビルドとテスト
• リリース時の自動デプロイメント
• Issue作成時の自動ラベル付け

ワークフロー同士を参照することも可能で、共通処理を再利用できます。

3.2. イベント（Events）

イベントは、ワークフローをトリガーする具体的な活動です。GitHubで発生する様々なアクションに対応しています。

• push: コードのプッシュ
• pull_request: プルリクエストの作成・更新
• issues: Issueの作成・更新
• schedule: 定期実行（cronスケジュール）
• workflow_dispatch: 手動実行
• repository_dispatch: REST API経由での実行

3.3. ジョブ（Jobs）

ジョブは、同一のランナー上で実行される一連のステップの集合です。各ステップはシェルスクリプトまたはアクションのいずれかで、順番に実行され、互いに依存します。同じランナー上で実行されるため、ステップ間でデータを共有できます。

デフォルトではジョブは依存関係を持たず並列実行されますが、他のジョブへの依存関係を設定することで順次実行も可能です。依存関係を持つジョブは、依存先のジョブが完了するまで待機してから実行されます。

マトリックスを使用すると、同じジョブを異なる変数の組み合わせ（OSや言語バージョンなど）で複数回実行できます。

たとえば、複数のアーキテクチャ向けのビルドジョブを依存関係なしで並列実行し、すべてが成功した後にパッケージングジョブを実行する、といった構成が可能です。

3.4. アクション（Actions）

アクションは、ワークフロー内で特定のタスクを実行する、事前定義された再利用可能なコードセットです。ワークフローファイルに記述する繰り返しコードの量を削減します。

• リポジトリのチェックアウト
• ビルド環境のセットアップ
• クラウドプロバイダーへの認証

自作のアクションを作成することも、GitHub Marketplaceで公開されているアクションを利用することもできます。

3.5. ランナー（Runners）

ランナーは、トリガーされたときにワークフローを実行するサーバーです。各ランナーは一度に1つのジョブを実行します。

GitHubが提供するホストランナーは以下のOSに対応しています。

• Ubuntu Linux
• Microsoft Windows
• macOS

各ワークフロー実行は、新規にプロビジョニングされた仮想マシン上で行われます。

より大規模な構成が必要な場合は、より大きなランナーも利用可能です。また、異なるOSや特定のハードウェア構成が必要な場合は、セルフホストランナーを自前のデータセンターやクラウドインフラで実行できます。

4. 実践: 最初のワークフローを作成する

実際にワークフローを作成してみましょう。以下は、コードがプッシュされるたびに実行される基本的なワークフローの例です。

4.1. 前提条件

• GitHubの基本的な使用方法（リポジトリ、ブランチ、プルリクエスト）の理解
• ファイルを追加できるGitHub上のリポジトリ
• GitHub Actionsへのアクセス権限

リポジトリの「Actions」タブが表示されない場合は、そのリポジトリでActionsが無効になっている可能性があります。

4.2. ワークフローファイルの作成

リポジトリ内に.github/workflows/github-actions-demo.ymlを作成します。

.github/workflowsディレクトリが既に存在する場合は、そのディレクトリに移動して「Add file」→「Create new file」をクリックし、github-actions-demo.ymlという名前を付けます。

リポジトリに.github/workflowsディレクトリがない場合は、リポジトリのメインページで「Add file」→「Create new file」をクリックし、.github/workflows/github-actions-demo.ymlという名前を付けます。これにより、.githubとworkflowsディレクトリ、およびgithub-actions-demo.ymlファイルが一度に作成されます。

GitHubがリポジトリ内のGitHub Actionsワークフローを検出するには、ワークフローファイルを.github/workflowsというディレクトリに保存する必要があります。

ワークフローファイルには任意の名前を付けることができますが、ファイル拡張子として.ymlまたは.yamlを使用する必要があります。YAMLは、設定ファイルによく使用されるマークアップ言語です。

以下のYAML内容をgithub-actions-demo.ymlファイルにコピーします。

name: GitHub Actions Demo
run-name: ${{ github.actor }} がGitHub Actionsをテスト中 🚀
on: [push]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 このジョブは ${{ github.event_name }} イベントによって自動的にトリガーされました。"
      - run: echo "🐧 このジョブは現在、GitHubがホストする ${{ runner.os }} サーバー上で実行されています！"
      - run: echo "🔎 ブランチ名は ${{ github.ref }} で、リポジトリは ${{ github.repository }} です。"
      - name: Check out repository code
        uses: actions/checkout@v5
      - run: echo "💡 ${{ github.repository }} リポジトリがランナーにクローンされました。"
      - run: echo "🖥️ ワークフローは、ランナー上でコードをテストする準備ができました。"
      - name: List files in the repository
        run: |
          ls ${{ github.workspace }}
      - run: echo "🍏 このジョブのステータスは ${{ job.status }} です。"

現時点では、このワークフローの詳細を理解する必要はありません。まずはファイルに内容をコピーして貼り付けてください。

「Commit changes」をクリックします。「Propose changes」ダイアログで、デフォルトブランチにコミットするオプション、または新しいブランチを作成してプルリクエストを開始するオプションのいずれかを選択します。その後、「Commit changes」または「Propose changes」をクリックします。

ワークフローファイルをリポジトリのブランチにコミットすると、pushイベントがトリガーされ、ワークフローが実行されます。

プルリクエストを開始することを選択した場合、プルリクエストの作成を続行できますが、このクイックスタートの目的では必須ではありません。コミットはブランチに対して行われており、新しいワークフローがトリガーされます。

4.3. ワークフロー実行結果の確認

リポジトリのメインページに移動します。リポジトリ名の下にある「Actions」タブをクリックします。

左サイドバーで、表示したいワークフロー（この例では「GitHub Actions Demo」）をクリックします。

ワークフロー実行のリストから、表示したい実行の名前（この例では「ユーザー名 is testing out GitHub Actions」）をクリックします。

ワークフロー実行ページの左サイドバーの「Jobs」の下にある、「Explore-GitHub-Actions」ジョブをクリックします。

ログには、各ステップがどのように処理されたかが表示されます。いずれかのステップを展開して、その詳細を確認できます。

たとえば、リポジトリ内のファイルのリストを確認できます。

このワークフローは、コードがブランチにプッシュされるたびにトリガーされ、GitHub Actionsがリポジトリのコンテンツとどのように連携できるかを示しています。

5. 継続的インテグレーション（CI）について

5.1. 継続的インテグレーションとは

継続的インテグレーション（CI）は、頻繁にコードを共有リポジトリにコミットすることを求めるソフトウェアプラクティスです。コードを頻繁に更新することで、エラーを早期に検出し、エラーの原因を見つける際にデバッグが必要なコード量を削減できます。頻繁なコード更新により、ソフトウェア開発チームの異なるメンバーからの変更をマージすることも容易になります。これは開発者にとって大きなメリットがあり、コードの記述により多くの時間を費やし、エラーのデバッグやマージ競合の解決に費やす時間を減らすことができます。

リポジトリにコードをコミットする際、コミットがエラーを導入していないことを確認するために、コードを継続的にビルドおよびテストできます。テストには、コードリンター（スタイルフォーマットをチェック）、セキュリティチェック、コードカバレッジ、機能テスト、その他のカスタムチェックを含めることができます。

コードのビルドとテストにはサーバーが必要です。リポジトリにコードをプッシュする前にローカルで更新をビルドおよびテストすることも、リポジトリ内の新しいコードコミットをチェックするCIサーバーを使用することもできます。

5.2. GitHub Actionsを使用した継続的インテグレーション

GitHub Actionsを使用したCIは、リポジトリ内のコードをビルドし、テストを実行できるワークフローを提供します。ワークフローは、GitHubホストの仮想マシン、または自前でホストするマシン上で実行できます。

GitHubイベントが発生したとき（たとえば、新しいコードがリポジトリにプッシュされたとき）、設定されたスケジュールで、またはrepository dispatch webhookを使用して外部イベントが発生したときに、CIワークフローを実行するように設定できます。

GitHubはCIテストを実行し、各テストの結果をプルリクエストに表示するため、ブランチの変更がエラーを導入しているかどうかを確認できます。ワークフロー内のすべてのCIテストが合格すると、プッシュした変更をチームメンバーがレビューしたり、マージしたりする準備が整います。テストが失敗した場合、変更の1つが失敗の原因となった可能性があります。

リポジトリにCIを設定すると、GitHubはリポジトリ内のコードを分析し、リポジトリ内の言語とフレームワークに基づいてCIワークフローを推奨します。たとえば、Node.jsを使用している場合、GitHubはNode.jsパッケージをインストールしてテストを実行するワークフローテンプレートを提案します。GitHubが提案するCIワークフローテンプレートを使用したり、提案されたワークフローテンプレートをカスタマイズしたり、独自のカスタムワークフローファイルを作成してCIテストを実行したりできます。

プロジェクトのCIワークフローを設定するのに役立つだけでなく、GitHub Actionsを使用して、ソフトウェア開発ライフサイクル全体にわたってワークフローを作成できます。たとえば、アクションを使用してプロジェクトをデプロイ、パッケージ化、またはリリースできます。

5.3. CI実行の流れ

6. 継続的デプロイメント（CD）について

6.1. 継続的デプロイメントとは

継続的デプロイメント（CD）は、自動化を使用してソフトウェア更新を公開およびデプロイするプラクティスです。通常のCDプロセスの一部として、コードはデプロイ前に自動的にビルドおよびテストされます。

継続的デプロイメントは、多くの場合、継続的インテグレーションと組み合わせて使用されます。

6.2. GitHub Actionsを使用した継続的デプロイメント

GitHub Actionsワークフローを設定して、ソフトウェア製品をデプロイできます。製品が期待どおりに動作することを確認するために、ワークフローはリポジトリ内のコードをビルドし、デプロイ前にテストを実行できます。

イベントが発生したとき（たとえば、新しいコードがリポジトリのデフォルトブランチにプッシュされたとき）、設定されたスケジュールで、手動で、またはrepository dispatch webhookを使用して外部イベントが発生したときに、CDワークフローを実行するように設定できます。

GitHub Actionsは、デプロイメントをより細かく制御するための機能を提供します。たとえば、環境を使用してジョブの進行に承認を要求したり、ワークフローをトリガーできるブランチを制限したり、シークレットへのアクセスを制限したりできます。並行性を使用して、CDパイプラインを最大1つの進行中のデプロイメントと1つの保留中のデプロイメントに制限できます。

6.3. ワークフローテンプレートとサードパーティアクション

GitHubは、Azure Web Appなどのいくつかの人気サービス向けのデプロイメントワークフローテンプレートを提供しています。

多くのサービスプロバイダーは、GitHub Marketplaceでサービスへのデプロイ用のアクションも提供しています。

6.4. デプロイメントワークフローの例

6.5. OpenID Connectの活用

GitHub ActionsワークフローがOpenID Connect（OIDC）をサポートするクラウドプロバイダーのリソースにアクセスする必要がある場合、ワークフローをクラウドプロバイダーに直接認証するように設定できます。これにより、これらの認証情報を長期間有効なシークレットとして保存することを停止でき、その他のセキュリティ上の利点が得られます。

7. ワークフローテンプレートの使用

7.1. ワークフローテンプレートについて

GitHubは、そのまま使用したり、独自のワークフローを作成するためにカスタマイズしたりできる、事前設定済みのワークフローテンプレートを提供しています。GitHubはコードを分析し、リポジトリに役立つ可能性のあるワークフローテンプレートを表示します。たとえば、リポジトリにNode.jsコードが含まれている場合、Node.jsプロジェクトの提案が表示されます。

これらのワークフローテンプレートは、以下のような様々な設定を提供し、すぐに使い始められるように設計されています。

• CI: 継続的インテグレーションワークフロー
• Deployments: デプロイメントワークフロー
• Automation: 自動化ワークフロー
• Code Scanning: コードスキャンワークフロー
• Pages: Pagesワークフロー

これらのワークフローをカスタムワークフローを構築するための出発点として使用するか、そのまま使用できます。actions/starter-workflowsリポジトリで、ワークフローテンプレートの完全なリストを参照できます。

8. GitHub Actions vs GitHub Apps

8.1. GitHub Appsの特徴

• 永続的に実行され、イベントに素早く反応できる
• 永続的なデータが必要な場合に適している
• 時間のかからないAPIリクエストに最適
• 提供するサーバーまたはコンピューティングインフラ上で実行

8.2. GitHub Actionsの特徴

• 継続的インテグレーションと継続的デプロイメントを実行できる自動化を提供
• ランナーマシンまたはDockerコンテナで直接実行可能
• リポジトリのクローンへのアクセスを含めることができ、デプロイおよび公開ツール、コードフォーマッター、コマンドラインツールがコードにアクセスできる
• コードをデプロイしたり、アプリを提供したりする必要がない
• シークレットを作成および使用するためのシンプルなインターフェースを持ち、アクションを使用する人の認証情報を保存する必要なく、サードパーティサービスと対話できる

9. まとめ

GitHub Actionsは、GitHubエコシステムに深く統合されたCI/CDプラットフォームとして、開発ワークフローの自動化を実現します。

主な特徴:

• GitHubリポジトリとの完全な統合
• 豊富なワークフローテンプレートとMarketplaceのアクション
• 柔軟なトリガー設定とイベント駆動型の実行
• GitHubホストランナーとセルフホストランナーの選択肢
• 環境、シークレット、並行性制御などの高度な機能

プロジェクトの規模や要件に応じて、提供されているテンプレートから始めることも、完全にカスタマイズしたワークフローを構築することも可能です。まずは小さなワークフローから始めて、段階的に自動化の範囲を広げていくことをお勧めします。

GitHub Actionsを活用することで、手動作業を削減し、コードの品質を向上させ、より迅速なリリースサイクルを実現できます。