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 のランナーが利用可能
外部サービスのセットアップや認証設定が不要で、リポジトリにYAMLファイルを追加するだけで始められます。
Step 2ワークフローファイルの構造
GitHub Actionsのワークフローは、リポジトリの .github/workflows/ ディレクトリにYAMLファイルとして配置します。
my-project/
├── .github/
│ └── workflows/
│ ├── ci.yml # テスト自動実行
│ ├── deploy.yml # 自動デプロイ
│ └── scheduled.yml # 定期実行タスク
├── src/
├── tests/
└── README.md
基本的なワークフローファイルの構成を見てみましょう。
# ワークフロー名(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 | ジョブ内の個々の処理 | 必須 |
タブ文字を使うとパースエラーになるため、エディタの設定で「タブをスペースに変換」を有効にしておきましょう。
Step 3トリガーの設定 — push, pull_request, schedule
GitHub Actionsでは、onキーでワークフローの実行条件(トリガー)を指定します。用途に応じて複数のトリガーを組み合わせることが可能です。
push トリガー
指定したブランチやパスへのpush時にワークフローを実行します。
on:
push:
# 特定のブランチのみ
branches:
- main
- develop
# 特定のパスのみ(src配下の変更時のみ実行)
paths:
- 'src/**'
- 'tests/**'
# 特定のパスを除外
paths-ignore:
- '*.md'
- 'docs/**'
pull_request トリガー
プルリクエストの作成・更新時にワークフローを実行します。コードレビュー前のテスト自動実行に最適です。
on:
pull_request:
branches: [ main ]
# 特定のアクティビティタイプのみ
types:
- opened # PR作成時
- synchronize # PRに新しいコミットがpushされた時
- reopened # PRが再オープンされた時
schedule トリガー(cron)
cron構文で定期実行を設定できます。ナイトリービルドやセキュリティスキャンに便利です。
on:
schedule:
# 毎日UTC 0:00(JST 9:00)に実行
- cron: '0 0 * * *'
# 毎週月曜UTC 3:00(JST 12:00)に実行
- cron: '0 3 * * 1'
その他の便利なトリガー
| トリガー | 説明 | 用途 |
|---|---|---|
workflow_dispatch | 手動実行ボタンを追加 | 任意のタイミングで実行したいとき |
release | リリース作成時 | リリースビルド・パッケージ公開 |
issues | Issue操作時 | 自動ラベル付け・通知 |
workflow_call | 他のワークフローから呼び出し | 共通処理の再利用 |
# 手動実行 + パラメータ入力
on:
workflow_dispatch:
inputs:
environment:
description: 'デプロイ先環境'
required: true
default: 'staging'
type: choice
options:
- staging
- production
scheduleトリガーはデフォルトブランチ(通常はmain)のワークフローファイルのみが有効です。また、リポジトリに60日以上アクティビティがないと、自動的に無効化されることがあります。
Step 4ジョブとステップ
ワークフローは1つ以上のジョブ(job)で構成され、各ジョブは複数のステップ(step)を持ちます。
ジョブの並列実行と依存関係
デフォルトでは複数のジョブは並列に実行されます。needsキーで依存関係を定義すると、順序を制御できます。
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を使うと、複数の環境やバージョンの組み合わせでテストを並列実行できます。
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' } |
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 — リポジトリのチェックアウト
ほぼすべてのワークフローで最初に使う、リポジトリのコードを取得するアクションです。
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環境のセットアップ
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環境のセットアップ
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 — 依存関係のキャッシュ
依存関係のインストールを高速化するためのキャッシュアクションです。
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@v5 | Dockerイメージのビルドとプッシュ |
aws-actions/configure-aws-credentials@v4 | AWS認証の設定 |
peaceiris/actions-gh-pages@v4 | GitHub Pagesへのデプロイ |
@v4)またはコミットSHAを指定しましょう。@mainや@latestのような指定は、予期しない変更でワークフローが壊れる原因になります。セキュリティ上重要な場合は、SHAで固定するのがベストです:
uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608
Step 6実践例 — テスト自動実行と自動デプロイ
ここまでの知識を組み合わせて、実際のプロジェクトで使えるワークフローを構築してみましょう。
実践例1: Djangoプロジェクトのテスト自動実行
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自動ビルド&デプロイ
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にテスト結果をコメント
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
プライベートリポジトリ: 月2,000分の無料枠(Freeプラン)。超過分は従量課金。
macOSランナーはLinuxの10倍、WindowsランナーはLinuxの2倍のコストがかかるため、テストはLinuxランナーを基本にするのがおすすめです。
- ワークフローファイルは
.github/workflows/に配置 onでトリガー、jobsでジョブを定義needsでジョブの実行順序を制御strategy.matrixで複数環境のテストを並列実行- 機密情報は必ずSecretsに保存し、
${{ secrets.NAME }}で参照 - アクションのバージョンは固定して予期しない破壊を防ぐ