← Back to Home

GitHub Actions入門：フロントエンド開発者のためのCI/CD自動化完全ガイド

#GitHub#CI/CD#DevOps#Frontend

Webフロントエンド開発において、「自動化」はもはやバックエンドやインフラエンジニアだけのものではありません。 ちょっとした文法エラー（Lintエラー）やテストの失敗によって、本番環境の画面が真っ白にクラッシュする事故を防ぐためには、CI/CD (Continuous Integration / Continuous Deployment: 継続的インテグレーション/継続的デプロイ) の導入が不可欠です。

本記事では、フロントエンドエンジニアの皆さんが絶対に知っておくべき「GitHub Actions」を使った自動化ワークフローの構築方法を基礎からわかりやすく解説します。

GitHub Actions Successful Workflow

1. CI/CDのメリットとは？

「手動で気をつければいいじゃないか」と思うかもしれません。しかし、人間は必ずミスをします。

  • 誰かが console.log() や debugger を消し忘れてプッシュした
  • 新しい機能を追加したが、関係ない別の画面が壊れた（リグレッション）
  • ローカル環境では動いたが、サーバー環境（Node.jsのバージョン違いなど）では動かないコードだった

**CI（継続的インテグレーション）**は、こういったヒューマンエラーを機械に検知させる仕組みです。 新しいコードがGitHubにプッシュされるたびに、専用のコンピューターが自動的に立ち上がり、コードの文法チェック・静的解析（Lint）・自動テストを走らせます。もしエラーが1つでもあれば、問題のコードが main ブランチに合流（マージ）されるのを強力にブロックします。

**CD（継続的デプロイメント）**は、この「安全だと証明されたコード」を人間の手を介さずして、自動で本番環境のサーバー（例: Vercel, AWS, Cloudflare Pages 等）へ公開する一連の流れを指します。

2. 実践！GitHub Actions 最初のステップ

GitHub Actions は、リポジトリの中に特定の書き方で設計図（YAMLファイル）を置くだけで機能します。 まずは、フロントエンド開発で最も基本的な「自動Lintチェックとテスト」の設計図を作ってみましょう。

プロジェクトのルート（一番上）に .github/workflows/ci.yml というファイルを作成します。

# .github/workflows/ci.yml
name: Frontend CI

# どのようなタイミングでこの設定（ワークフロー）を走らせるか
on:
  push:
    branches: [ "main" ] # mainブランチにプッシュされた時
  pull_request:
    branches: [ "main" ] # mainブランチに向けてPRが作られた時

# 自動で実行する作業のまとまり（ジョブとステップ）
jobs:
  build_and_test:
    runs-on: ubuntu-latest # 使用する仮想PCのOSを指定

    steps:
    # 1. 仮想PCの中にGitHubのソースコードをダウンロード（チェックアウト）する
    - name: Checkout Repository
      uses: actions/checkout@v4

    # 2. Node.js環境を構築する
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '24' # 使いたいNodeのバージョン
        cache: 'npm' # npmのインストールを高速化するためのキャッシュ機能

    # 3. パッケージ（依存関係）をインストールする
    - name: Install Dependencies
      run: npm ci # npm installよりも厳格にバージョン固定インストールを行う

    # 4. Lint（静的解析）を実行する
    - name: Run ESLint
      run: npm run lint

    # 5. TypeScriptの型チェックを実行する
    - name: Type Check
      run: npm run typecheck

    # 6. 自動テストを実行する
    - name: Run Unit Tests
      run: npm run test

この設定ファイルの解説

  • on: push, pull_request: 新しくPull Request（PR）を作った瞬間に自動でこのテストが裏側で走ります。GitHubのPR画面を見ると、緑色のチェック ✅ や赤いバツ ❌ が表示されるアレです。
  • actions/setup-node: GitHub側が用意してくれている便利なひな形（アクション）です。これを使うだけで、最新のNode.js環境が一瞬で構築されます。
  • npm ci: npm install の代わりにCI環境でよくつかわれます。package-lock.json の内容と完全に合致するインストールを行い、依存関係のバージョンずれによる「ローカルでは動いたんだけどな問題」を防ぎます。

3. Pull Requestの品質を担保する「必須設定」

ただActionsを動かすだけではなく、GitHubの設定（リポジトリの Settings > Branches）から "Require status checks to pass before merging" を有効化することを強くお勧めします。

これを設定しておくと、PRを作って Actions のテストが失敗（赤字）になった場合、**「テストが通るまで、Merge（統合）ボタンが押せないようにロック」**してくれます。これにより、完全に壊れたコードが本番に混ざることをシステム単位でシャットアウトできます。

4. 自動フォーマット（Prettier）との連携

さらに進んだテクニックとして、コードのインデントや改行ルールの綺麗さを保つ Prettier をActionsで実行させることもできます。 もしフォーマット規則に違反していた場合、Actions上で「ここのコードが汚いですよ」と自動でPRにコメントを付けたり、Actions自体に綺麗に修正（npm run format）させてコミットを追加させるような構築も可能です。

これにより、チーム開発における「コードレビューでの不毛なインデント指摘・フォーマット論争」から全員が解放され、より本質的なロジックの設計やタイポの指摘に時間を避けるようになります。

5. まとめ：自動化に投資しよう初耳

最初の構築こそ「YAMLの書き方がわからない」「謎のエラーで失敗する」と挫折しやすい CI/CD ですが、一度正しくセットアップしてしまえば、プロジェクトが終了するまでの間、数え切れないほどのエラーや手戻りの時間を削減してくれる最高の社内エンジニアとして働いてくれます。

個人的なブログや、一人で作っている「TODOアプリ」などの小さな趣味プロジェクトでこそ、この Actions の実験と学習を行うのに最適です。ぜひ、今日からあなたのリポジトリに .github/workflows/ フォルダを追加してみてください。