GitHub Actionsで学ぶCI/CDパイプライン

コミットをプッシュした後、手動でテストを実行し、アプリをビルドし、サーバーにファイルをアップロードしていませんか？それは機能しますが、遅く、エラーが発生しやすく、スケールしません。そこでCI/CDパイプラインの出番です。

このガイドでは、CI/CDの概念を分解し、GitHub Actionsで実際のパイプラインを構築する方法を紹介します。最後には、あらゆるプロジェクトのテスト、ビルド、デプロイを自動化する方法を理解できるでしょう。

CI/CDとは何か？

CI（継続的インテグレーション）は、コード変更を自動的にテストし、共有ブランチにマージするプラクティスです。プッシュするたびにビルドとテストが実行され、統合の問題を早期に発見できます。

CD（継続的デリバリー/デプロイ）はCIを拡張し、アプリケーションを自動的に準備（およびオプションでデプロイ）して本番環境に送ります。継続的デリバリーはコードが常にデプロイ可能な状態を意味し、継続的デプロイは自動的にデプロイされることを意味します。

これらを合わせて、CI/CDはパイプラインを形成します：コミットから本番環境まで、一連の自動化されたステップです。

なぜCI/CDにGitHub Actionsを使うのか？

GitHub ActionsはGitHubに組み込まれたCI/CDプラットフォームです。パブリックリポジトリでは無料で、プライベートリポジトリでも十分な分数が提供されます。主な利点：

• 統合されている：外部サービスは不要で、ワークフローはリポジトリ内にあります。
• イベント駆動型：プッシュ、プルリクエスト、スケジュール、手動ディスパッチでワークフローをトリガーできます。
• 拡張可能：GitHub Marketplaceには数千の既成アクションがあります。
• マトリックスビルド：複数のOSと言語バージョンで簡単にテストできます。

GitHub Actionsのコア概念

最初のワークフローを書く前に、これらの用語を理解しましょう：

最初のCIパイプラインを構築する

Node.jsプロジェクト用の基本的なCIワークフローを作成しましょう。メインブランチへのプッシュとプルリクエストごとにテストを実行します。

.github/workflows/ci.yml を作成します：

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test

このワークフローは：

1. main へのプッシュとPRでトリガーされます。
2. 最新のUbuntuランナーで test というジョブを実行します。
3. マトリックスを使用してNode.js 18と20でテストします。
4. コードをチェックアウトし、Nodeをセットアップし、依存関係をインストールし、テストを実行します。

このファイルをプッシュしてActionsタブを見てください。2つの並列ジョブ（Nodeバージョンごとに1つ）が表示されます。テストが失敗すると、ワークフローが失敗し、GitHubが通知します。

継続的デプロイを追加する

CIは素晴らしいですが、CDは自動化が真価を発揮する場所です。メインブランチでテストが成功した後にサーバーにデプロイするようにワークフローを拡張しましょう。

test に依存し、main へのプッシュ時のみ実行される deploy ジョブを追加します。

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Deploy to server
      uses: appleboy/ssh-action@v1.0.0
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USER }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          cd /var/www/myapp
          git pull origin main
          npm ci --production
          pm2 restart myapp

重要なポイント：

• needs: test はテストが成功した場合にのみデプロイが実行されることを保証します。
• if 条件は main へのプッシュにデプロイを制限します。
• シークレット（SSH_HOST、SSH_USER、SSH_KEY）はGitHubリポジトリ設定に保存され、安全に注入されます。

このパターンは多くのデプロイ先で機能します：SSH、Dockerレジストリ、クラウドプラットフォーム（AWS、Vercel、Netlify）、またはKubernetes。

GitHub Actionsを使ったCI/CDのベストプラクティス

• ワークフローを高速に保つ：依存関係をキャッシュ（例：actions/cache）してビルド時間を短縮します。
• 早期に失敗させる：遅いテストの前に迅速なチェック（リンティング）を実行します。
• 環境を使用する：本番デプロイ用の保護ルールを設定します。
• シークレットを安全に：認証情報をハードコードせず、GitHub Secretsを使用します。
• 監視とアラート：失敗したワークフローの通知を設定します。

失敗したワークフローのデバッグ

ワークフローが失敗すると、GitHubは各ステップのログを表示します。よくある問題：

• 依存関係の欠落：テストの前に npm ci または同等のコマンドが実行されることを確認します。
• 不正なシークレット：名前と値を再確認します。
• 権限エラー：ランナーの権限とSSHキーを確認します。

リポジトリシークレット ACTIONS_STEP_DEBUG を true に設定してデバッグログを有効にすることもできます。

FAQ

CIとCDの違いは何ですか？

CIはコード変更のテストと統合を自動化します。CDはそれらの変更を環境に配信またはデプロイすることを自動化します。CIはコード品質を保証し、CDはユーザーに迅速かつ確実に届くことを保証します。

GitHub Actionsは無料ですか？

GitHub Actionsはパブリックリポジトリでは無料です。プライベートリポジトリでは、毎月の無料分数（例：Freeアカウントで2,000分）が提供され、追加使用には料金がかかります。セルフホストランナーもオプションです。

GitHub以外のプロジェクトでもGitHub Actionsを使えますか？

はい、GitHub Actionsは任意のコマンドラインツールを実行できます。コードがGitHub上にあるか、アクションで取得する限り、他の場所でホストされているプロジェクトのビルドとデプロイに使用できます。

CI/CDを効率化する準備はできましたか？まずGitHub Actionsでテストを自動化することから始めましょう。デプロイログを素早く分析する方法として、各デプロイ後にエラーやパフォーマンス問題を発見するNginx Log Analyzerをお試しください。