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ファイルを作って置くだけでぐっと楽になります
「ちょっと面倒だな…」と思いがちなビルド・テスト・デプロイの手順がすっきり整理できるのが魅力的ですよね
もし同じような手動作業を繰り返している方がいれば、ぜひ一度試してみてはいかがでしょうか？