GitHub ActionsでCI/CDを初めて実装してみた

こんにちは！
今回は初めてGitHub Actionsを使ったCI/CDを試してみたので、実際に「どんな構成で動かしているか」「どうやって設定したか」を紹介しつつ、CI/CDとは何なのかも含めて簡単にまとめてみたいと思います。

もし気になる点や「ここはこうしたほうがいいのでは？」といったご意見があれば、コメントいただけると嬉しいです

そもそもCI/CDってなんでしょうか？

CI（Continuous Integration）
新しいコードをコミット（またはプルリク）するたびに、テストやビルドを自動で回して品質を担保しよう、という考え方です。
例えるなら「食材が届くたびに味見をして、ちゃんと料理できる状態か確認する」イメージでしょうか？
CD（Continuous Delivery / Continuous Deployment）
テストなどをパス→速やかにデプロイまでつなげてしまおう、という流れ。
「味見OKなら、そのままお皿に盛ってお客さんのところへ出す」イメージに近いかもしれません

GitHub Actionsを使うと、開発フローをほぼ自動化できるので、手作業が減ってとても快適です
今回は実際に試してみた事例を、できるだけシンプルに紹介してみます

私のプロジェクトで設定したワークフロー

1. CI（テスト & ビルド）

どんな動きをしているのか

mainブランチにコードがpushされるか、プルリクが作成されると自動でテスト・ビルドが走ります
テストに落ちるとすぐに通知が届くため、問題を早期に発見できるように

CI.yml の内容

name: CI

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

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js
        uses: actions/setup-node@v2
        with:
          node-version: "18.x"
          cache: "npm"

      - name: Install dependencies
        run: npm ci
        working-directory: ./lead-agent

      - name: Build
        run: npm run build
        working-directory: ./lead-agent

      - name: Run tests
        run: npm test
        working-directory: ./lead-agent
        env:
          CI: true

ここでのポイント
依存関係のキャッシュを有効にすることでビルド時間を短縮

テストに失敗したらここで止まる

つまり、後続の処理や本番リリースには影響させないようにしています

成果物の作成・アップロード
どんな動きをしているのか
上のCI（ビルド・テスト）が成功した場合にのみ、Dockerイメージのビルドや成果物のアップロードを行うワークフロー

将来的にはここから本番環境へデプロイしたり、別の処理を連携させたりする予定です

deploy.yml の内容

name: Build and Create Artifacts

on:
  workflow_run:
    workflows: ["CI"]
    branches: [main]
    types:
      - completed

jobs:
  build_artifacts:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Setup Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '18.x'

      - name: Install dependencies
        run: npm ci
        working-directory: ./lead-agent

      - name: Build application
        run: npm run build
        working-directory: ./lead-agent

      - name: Create Docker image (without push)
        run: |
          cd lead-agent
          # タグを使わずにビルドのみ実行（テスト用）
          docker build -t lead-agent:test .

      - name: Upload build artifacts
        uses: actions/upload-artifact@v2
        with:
          name: build-artifacts
          path: |
            lead-agent/dist
            lead-agent/package.json
            lead-agent/Dockerfile

ここでのポイント

workflow_run を使って「CIが終わったらこのワークフローを実行」という連携を実現
if: ${{ ... }} の条件で**CIが成功（テスト通過）**の場合だけ実行
Dockerイメージのビルドはテスト目的でやっているため、今後は本番へのpushなどに活用する余地がありそうです

実際にやってみて感じたメリット

1. エラーの早期発見がラク

手動テストなしでも、pushした時点で問題があれば自動で報告されます
これにより「いつの間にかビルドできない…」という事故を防ぎやすくなります

2. 手動作業がすっきり

npm install → ビルド → テスト → Dockerビルド → 成果物まとめ など、地味に面倒な作業をすべて自動化。
時間の節約にもなり、開発に集中しやすくなります

3. 品質と効率が上がる

テストをパスしたコードのみが後続に進むため、本番に問題のあるコードが混ざるリスクが大幅に減少します

私が感じた今後の拡張ポイント

本番デプロイを自動化
- VercelやAWSに直接デプロイするフローを追加して、リリースの手間をより削減
SlackやDiscord通知
- 「テストに失敗したとき」や「デプロイが完了したとき」に通知を飛ばせると、さらに便利に
LintやESLintチェックの自動化
- コードスタイルチェックを組み込めば、きれいなコードを保ちやすくなる

まとめ

今回は実際に試したGitHub ActionsによるCI/CDの一例を紹介してみました。
CI/CDと聞くと少しハードルが高そうに思えるかもしれませんが、YAMLファイルを作って置くだけでぐっと楽になります

「ちょっと面倒だな…」と思いがちなビルド・テスト・デプロイの手順がすっきり整理できるのが魅力的ですよね
もし同じような手動作業を繰り返している方がいれば、ぜひ一度試してみてはいかがでしょうか？