初めてGitHub ActionsでCI/CDをやってみた話

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

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

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

---

## そもそもCI/CDってなんでしょうか？
- **CI（Continuous Integration）**  
  新しいコードをコミット（またはプルリク）するたびに、テストやビルドを自動で回して品質を担保しよう、という考え方です。  
  例えるなら「食材が届くたびに味見をして、ちゃんと料理できる状態か確認する」イメージでしょうか？  

- **CD（Continuous Delivery / Continuous Deployment）**  
  テストなどをパス→速やかにデプロイまでつなげてしまおう、という流れ。  
  「味見OKなら、そのままお皿に盛ってお客さんのところへ出す」イメージに近いかもしれません

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

---

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

### 1. CI（テスト & ビルド）
#### :mag: どんな動きをしているのか
- mainブランチにコードがpushされるか、プルリクが作成されると自動でテスト・ビルドが走ります
- テストに落ちるとすぐに通知が届くため、問題を早期に発見できるように

### CI.yml の内容

```yaml
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
```

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

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

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

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

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

### deploy.yml の内容

```yaml
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
```

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

---

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

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

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

### 3. 品質と効率が上がる
テストをパスしたコードのみが後続に進むため、本番に問題のあるコードが混ざる**リスクが大幅に減少**します

---

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

1. **本番デプロイを自動化**  
   - VercelやAWSに直接デプロイするフローを追加して、リリースの手間をより削減

2. **SlackやDiscord通知**  
   - 「テストに失敗したとき」や「デプロイが完了したとき」に通知を飛ばせると、さらに便利に

3. **LintやESLintチェックの自動化**  
   - コードスタイルチェックを組み込めば、**きれいなコード**を保ちやすくなる
---

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

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