Git

GitHub Actions入門|CI/CDパイプラインを構築する

Git GitHub Actions CI/CD

GitHub Actions入門
CI/CDパイプラインを構築する

GitHub Actionsを使ったCI/CDパイプラインの構築方法を解説。
ワークフローの書き方、トリガー設定、テスト自動化、自動デプロイまで学べます。

こんな人向けの記事です

  • GitHub Actionsを使い始めたい
  • テストの自動実行を設定したい
  • CI/CDパイプラインを構築したい

Step 1GitHub Actionsとは — CI/CDの概要

GitHub Actionsは、GitHubが提供するCI/CD(継続的インテグレーション / 継続的デリバリー)プラットフォームです。リポジトリに対するpushやプルリクエストなどのイベントをトリガーに、テスト・ビルド・デプロイなどの処理を自動実行できます。

用語意味具体例
CI(継続的インテグレーション)コード変更のたびにテストやビルドを自動実行pushごとにユニットテストを実行
CD(継続的デリバリー)テスト通過後に本番環境へ自動デプロイmainブランチへのマージで自動デプロイ

GitHub Actionsの主な特徴は以下の通りです。

  • GitHubリポジトリに統合されており、追加サービスが不要
  • パブリックリポジトリなら無料で利用可能
  • YAMLファイルでワークフローを定義するため、バージョン管理できる
  • 豊富なマーケットプレイスから再利用可能なアクションを選べる
  • Linux / macOS / Windows のランナーが利用可能
他のCI/CDサービスとの比較
Jenkins、CircleCI、Travis CIなどのCI/CDサービスがありますが、GitHub ActionsはGitHubとの統合が最も深い点が最大の利点です。
外部サービスのセットアップや認証設定が不要で、リポジトリにYAMLファイルを追加するだけで始められます。

Step 2ワークフローファイルの構造

GitHub Actionsのワークフローは、リポジトリの .github/workflows/ ディレクトリにYAMLファイルとして配置します。

ディレクトリ構造
my-project/
├── .github/
│   └── workflows/
│       ├── ci.yml          # テスト自動実行
│       ├── deploy.yml      # 自動デプロイ
│       └── scheduled.yml   # 定期実行タスク
├── src/
├── tests/
└── README.md

基本的なワークフローファイルの構成を見てみましょう。

.github/workflows/ci.yml
# ワークフロー名(GitHub上で表示される)
name: CI

# トリガー:いつ実行するか
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

# ジョブ:何を実行するか
jobs:
  test:
    # 実行環境(ランナー)
    runs-on: ubuntu-latest

    # ステップ:ジョブ内の各処理
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: echo "Hello, GitHub Actions!"
キー役割必須
nameワークフローの名前任意
onトリガー(実行条件)必須
jobs実行するジョブの定義必須
runs-onジョブの実行環境必須
stepsジョブ内の個々の処理必須
YAMLのインデントに注意
YAMLはインデントでデータの階層構造を表します。スペース2つが一般的です。
タブ文字を使うとパースエラーになるため、エディタの設定で「タブをスペースに変換」を有効にしておきましょう。

Step 3トリガーの設定 — push, pull_request, schedule

GitHub Actionsでは、onキーでワークフローの実行条件(トリガー)を指定します。用途に応じて複数のトリガーを組み合わせることが可能です。

push トリガー

指定したブランチやパスへのpush時にワークフローを実行します。

.github/workflows/ci.yml
on:
  push:
    # 特定のブランチのみ
    branches:
      - main
      - develop
    # 特定のパスのみ(src配下の変更時のみ実行)
    paths:
      - 'src/**'
      - 'tests/**'
    # 特定のパスを除外
    paths-ignore:
      - '*.md'
      - 'docs/**'

pull_request トリガー

プルリクエストの作成・更新時にワークフローを実行します。コードレビュー前のテスト自動実行に最適です。

.github/workflows/ci.yml
on:
  pull_request:
    branches: [ main ]
    # 特定のアクティビティタイプのみ
    types:
      - opened        # PR作成時
      - synchronize   # PRに新しいコミットがpushされた時
      - reopened      # PRが再オープンされた時

schedule トリガー(cron)

cron構文で定期実行を設定できます。ナイトリービルドやセキュリティスキャンに便利です。

.github/workflows/scheduled.yml
on:
  schedule:
    # 毎日UTC 0:00(JST 9:00)に実行
    - cron: '0 0 * * *'
    # 毎週月曜UTC 3:00(JST 12:00)に実行
    - cron: '0 3 * * 1'

その他の便利なトリガー

トリガー説明用途
workflow_dispatch手動実行ボタンを追加任意のタイミングで実行したいとき
releaseリリース作成時リリースビルド・パッケージ公開
issuesIssue操作時自動ラベル付け・通知
workflow_call他のワークフローから呼び出し共通処理の再利用
.github/workflows/manual.yml
# 手動実行 + パラメータ入力
on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'デプロイ先環境'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production
scheduleトリガーの注意点
scheduleトリガーはデフォルトブランチ(通常はmain)のワークフローファイルのみが有効です。
また、リポジトリに60日以上アクティビティがないと、自動的に無効化されることがあります。

Step 4ジョブとステップ

ワークフローは1つ以上のジョブ(job)で構成され、各ジョブは複数のステップ(step)を持ちます。

ジョブの並列実行と依存関係

デフォルトでは複数のジョブは並列に実行されます。needsキーで依存関係を定義すると、順序を制御できます。

.github/workflows/pipeline.yml
jobs:
  # ジョブ1: テスト(最初に実行)
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

  # ジョブ2: ビルド(testの完了後に実行)
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm run build

  # ジョブ3: デプロイ(buildの完了後に実行)
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        run: echo "Deploying..."

マトリックス戦略

strategy.matrixを使うと、複数の環境やバージョンの組み合わせでテストを並列実行できます。

.github/workflows/ci.yml
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ['3.10', '3.11', '3.12']
        os: [ubuntu-latest, macos-latest]
      # 1つ失敗しても他は継続
      fail-fast: false

    steps:
      - uses: actions/checkout@v4
      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - name: Run tests
        run: python -m pytest

ステップの制御

キー説明
uses外部アクションを使用uses: actions/checkout@v4
runシェルコマンドを実行run: npm test
nameステップの表示名name: Run tests
if条件付き実行if: github.ref == 'refs/heads/main'
env環境変数の設定env: { NODE_ENV: production }
withアクションへの入力パラメータwith: { node-version: '20' }
.github/workflows/ci.yml
steps:
  - uses: actions/checkout@v4

  # 条件付き実行(mainブランチのみ)
  - name: Deploy to production
    if: github.ref == 'refs/heads/main'
    run: ./deploy.sh

  # 前のステップが失敗しても実行
  - name: Upload error logs
    if: failure()
    run: ./upload-logs.sh

  # 常に実行(成功・失敗問わず)
  - name: Cleanup
    if: always()
    run: ./cleanup.sh
ジョブ間のデータ共有
各ジョブは独立したランナーで実行されるため、ファイルシステムは共有されません。
ジョブ間でデータを受け渡すには、actions/upload-artifact / actions/download-artifact アクションを使うか、outputsで値を渡します。

Step 5よく使うアクション

GitHub Actionsのマーケットプレイスには、すぐに使える再利用可能なアクションが豊富に公開されています。特によく使うアクションを紹介します。

actions/checkout — リポジトリのチェックアウト

ほぼすべてのワークフローで最初に使う、リポジトリのコードを取得するアクションです。

.github/workflows/ci.yml
steps:
  # 基本的な使い方
  - uses: actions/checkout@v4

  # 履歴も含めてチェックアウト(git logが必要な場合)
  - uses: actions/checkout@v4
    with:
      fetch-depth: 0   # 全履歴を取得(デフォルトは1)

  # 別のリポジトリをチェックアウト
  - uses: actions/checkout@v4
    with:
      repository: owner/other-repo
      token: ${{ secrets.PAT_TOKEN }}

actions/setup-python — Python環境のセットアップ

.github/workflows/python.yml
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-python@v5
    with:
      python-version: '3.12'
      # pipのキャッシュを有効化
      cache: 'pip'
  - run: pip install -r requirements.txt
  - run: python -m pytest

actions/setup-node — Node.js環境のセットアップ

.github/workflows/node.yml
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: '20'
      # npmのキャッシュを有効化
      cache: 'npm'
  - run: npm ci
  - run: npm test

actions/cache — 依存関係のキャッシュ

依存関係のインストールを高速化するためのキャッシュアクションです。

.github/workflows/ci.yml
steps:
  - uses: actions/checkout@v4
  - uses: actions/cache@v4
    with:
      path: ~/.cache/pip
      # requirements.txtが変わったらキャッシュを更新
      key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
      restore-keys: |
        ${{ runner.os }}-pip-

その他のよく使うアクション

アクション用途
actions/upload-artifact@v4ビルド成果物やテストレポートのアップロード
actions/download-artifact@v4アップロードされた成果物のダウンロード
docker/build-push-action@v5Dockerイメージのビルドとプッシュ
aws-actions/configure-aws-credentials@v4AWS認証の設定
peaceiris/actions-gh-pages@v4GitHub Pagesへのデプロイ
アクションのバージョン固定
アクションを指定する際は、必ずメジャーバージョンタグ(例: @v4)またはコミットSHAを指定しましょう。
@main@latestのような指定は、予期しない変更でワークフローが壊れる原因になります。
セキュリティ上重要な場合は、SHAで固定するのがベストです:
uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608

Step 6実践例 — テスト自動実行と自動デプロイ

ここまでの知識を組み合わせて、実際のプロジェクトで使えるワークフローを構築してみましょう。

実践例1: Djangoプロジェクトのテスト自動実行

.github/workflows/django-ci.yml
name: Django CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    # サービスコンテナ(PostgreSQL)
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: testuser
          POSTGRES_PASSWORD: testpass
          POSTGRES_DB: testdb
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    env:
      DATABASE_URL: postgres://testuser:testpass@localhost:5432/testdb
      DJANGO_SETTINGS_MODULE: myproject.settings.test

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
          cache: 'pip'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run migrations
        run: python manage.py migrate

      - name: Run tests
        run: python -m pytest --cov=. --cov-report=xml

      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage.xml

実践例2: Docker自動ビルド&デプロイ

.github/workflows/deploy.yml
name: Build and Deploy

on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      # Docker Hubにログイン
      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      # Dockerイメージのビルドとプッシュ
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            myuser/myapp:latest
            myuser/myapp:${{ github.sha }}

      # SSHでサーバーにデプロイ
      - name: Deploy to server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /app
            docker compose pull
            docker compose up -d

シークレットの設定

パスワードやAPIキーなどの機密情報は、リポジトリのSettings → Secrets and variables → Actionsで設定します。

ワークフロー内でのシークレット参照
# シークレットは ${{ secrets.名前 }} で参照
env:
  API_KEY: ${{ secrets.API_KEY }}
  DATABASE_URL: ${{ secrets.DATABASE_URL }}

# 環境(Environment)ごとのシークレットも設定可能
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production   # production環境のシークレットを使用
    steps:
      - name: Deploy
        run: ./deploy.sh
        env:
          SERVER_HOST: ${{ secrets.SERVER_HOST }}
シークレットの取り扱い
シークレットの値はログに出力されると自動的にマスク(***)されますが、意図的にbase64エンコードして出力するなどの方法で漏洩する可能性があります。
サードパーティのアクションを使う際は、シークレットへのアクセス権限を慎重に確認しましょう。

実践例3: PRにテスト結果をコメント

.github/workflows/pr-comment.yml
name: PR Test Report

on:
  pull_request:
    branches: [ main ]

permissions:
  pull-requests: write

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests with report
        run: python -m pytest --junitxml=report.xml

      # テスト結果をPRにコメント
      - name: Publish test results
        uses: EnricoMi/publish-unit-test-result-action@v2
        if: always()
        with:
          files: report.xml
GitHub Actionsの料金
パブリックリポジトリ: 無料(制限なし)。
プライベートリポジトリ: 月2,000分の無料枠(Freeプラン)。超過分は従量課金。
macOSランナーはLinuxの10倍、WindowsランナーはLinuxの2倍のコストがかかるため、テストはLinuxランナーを基本にするのがおすすめです。
  • ワークフローファイルは .github/workflows/ に配置
  • onでトリガー、jobsでジョブを定義
  • needsでジョブの実行順序を制御
  • strategy.matrixで複数環境のテストを並列実行
  • 機密情報は必ずSecretsに保存し、${{ secrets.NAME }}で参照
  • アクションのバージョンは固定して予期しない破壊を防ぐ