はじめに
AIで普段開発をしており、「Pull Request（PR）を投げたらGitHub Actionsが走ってテストやLintが自動でチェックされる」という仕組みを導入しているのですが、立ち止まって調べてみました。
この記事では、「PRでの自動テストは知っているけれど、その先のCD（継続的デプロイ）や、CI/CDの本質的な全体像についてもっと深く理解したい！」という方向けに、現場で使われる実践的なワークフローを解説します。
1. そもそも「CI/CD」の全体像とは？
CI/CDは、「CI（継続的インテグレーション）」と「CD（継続的デリバリー / デプロイメント）」という2つのフェーズが繋がったパイプラインです。
[ コードを書く ]
│
▼
【 CI フェーズ 】 (PR作成時など)
├── 1. 静的解析 (Linter / Formatter)
├── 2. ユニットテスト / 統合テスト
└── 3. ビルド確認 (コンパイルチェック)
│
▼ 【マージ】
【 CD フェーズ 】 (mainブランチ等への反映時)
├── 4. アーティファクト作成 (Dockerイメージ化など)
├── 5. ステージング環境へ自動デプロイ ──> (人間による最終確認)
└── 6. 本番環境へデプロイ (Deliveryなら手動 / Deploymentなら自動)
── CI（Continuous Integration：継続的インテグレーション）
バグを早期に発見し、常に「動くコード」をメインブランチに維持するための仕組みです。
- 目的： 「他の人のコードと混ぜたら動かなくなった」「本番環境でクラッシュするコードだった」という事態を、マージする前に100%防ぐこと。
── CD（Continuous Delivery / Deployment）
CIを通過した安全なコードを、自動でユーザーが触れる環境に反映する仕組みです。これには現場の運用によって2つのレベルがあります。
-
継続的デリバリー（Continuous Delivery）：
本番一歩手前（ステージング環境）への反映や、本番公開の準備（ビルド）までは完全自動。最後の「本番公開ボタン」を押すのだけは人間が判断する運用。 -
継続的デプロイメント（Continuous Deployment）：
PRがmainブランチにマージされたら、人間の手を一切介さずにそのまま自動で本番環境までリリースされる運用。
2. GitHub Actionsで実現する「一歩進んだ自動化」
「PRのテスト」のほかに、GitHub Actionsを使うと以下のような高度なパイプラインを組むことができます。
① ビルド成果物（アーティファクト）の作成と保存
TypeScriptやReactのコンパイル、Next.jsのビルドなどをActions上で行います。また、Dockerイメージをビルドして AWS ECR や Docker Hub などのコンテナレジストリへ自動プッシュするのもCI/CDの定番です。
② クラウド環境への自動デプロイ（CDの実装）
GitHubの Settings > Secrets and variables > Actions に暗号化された認証情報（AWSのアクセスキーやVercelのトークンなど）を登録しておくことで、以下のようなデプロイが自動化できます。
- AWS（S3, ECS, Lambda, Amplify）への転送・更新
- GCP や Vercel、Render への自動デプロイ
③ セキュリティスキャン
コードをマージする前に、依存ライブラリに脆弱性がないかをチェックするツール（DependabotやTrivyなど）をワークフローに組み込めます。
④ リリースノート・Gitタグの自動生成
本番デプロイが完了したタイミングで、GitHubの「Releases」に自動でバージョンタグ（v1.2.0 など）を打ち、コミットメッセージから変更履歴（リリースノート）を自動生成させることができます。
3. 現場でよく使われる「GitHub Actions」の設計パターン
一般的なWeb開発の現場では、以下のようにGitHubのイベント（トリガー）ごとにファイル（.github/workflows/*.yml）を分けて運用します。
| トリガー（イベント） | 行うこと（Job） | 目的 |
|---|---|---|
on: pull_request |
Linter, Test, Build check | 【CI】 品質ガード。パスしないとマージできないようにブランチ保護ルールを設定する。 |
on: push (mainブランチ) |
Build, Docker Push, Staging Deploy | 【CD】 検証環境への自動反映。ここでE2Eテスト（Playwright等）を走らせることも。 |
on: release (公開時) |
Production Deploy, Slack通知 | 【CD】 本番環境への安全な一発リリースと、チームへの完了通知。 |
ワークフローのイメージ（mainにマージされたらAWSへデプロイする場合）
name: CD to AWS
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install and Build
run: |
npm ci
npm run build
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ap-northeast-1
- name: Deploy to S3
run: |
aws s3 sync ./dist s3://my-bucket-name --delete
まとめ
PRからCIが起動され、エラーがあれば弾かれる。ということを開発初期からやっていいるのですが、わかっているようで、わかっていなかったので、今回調査し、自分のためになったな。と思います。
同じようにCI/CDについて、少しでも理解が進んでくれた方がいれば何よりです。