ToDoアプリ（FastAPI + Next.js）は、CI/CDの教材として理想的な構成です。
ここでは、全体像を「何をどこで、どのように自動化するか」という流れで整理します。
（TDD/DDD設計を活かしつつ、最小限のYAML構成を頭に描けるようにします。）
🧭 まずゴールのイメージ
「pushしたらテスト・ビルドが自動で走り、mainにマージされたら自動デプロイされる」
🌍 全体構成図（ざっくり）
GitHub Actions (CI/CD)
├── CIフェーズ (push / PR時)
│ ├── バックエンドテスト (pytest)
│ ├── フロントエンドLint & Build
│ └── 共通チェック (フォーマット/型)
└── CDフェーズ (mainブランチマージ時)
├── Dockerイメージビルド
├── GHCRへPush
└── Vercel/Render/Fly.io等にデプロイ
🧩 1. CI：品質を自動で担保するフェーズ
「PRを出した瞬間に、バグを未然に防ぐ」
🧪 (1) バックエンド: FastAPI + pytest
目的：テストが通るか、型やフォーマットが崩れていないか を自動チェック。
実行内容
-
pytestでユニットテスト -
rufforflake8でLint -
mypyで型チェック
YAMLイメージ
# .github/workflows/backend-ci.yml
name: Backend CI
on:
pull_request:
push:
branches: [ main ]
jobs:
backend:
runs-on: ubuntu-latest
defaults:
run:
working-directory: apps/api
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.13'
cache: 'pip'
- name: Install dependencies
run: pip install fastapi uvicorn pydantic pytest ruff mypy
- name: Lint
run: ruff check .
- name: Type Check
run: mypy .
- name: Run tests
run: pytest -v
💅 (2) フロントエンド: Next.js
目的：Lintとビルドが成功するかを確認。
実行内容
npm run lint-
npm run build（SSR/静的生成のエラー検出）
YAMLイメージ
# .github/workflows/frontend-ci.yml
name: Frontend CI
on:
pull_request:
push:
branches: [ main ]
jobs:
frontend:
runs-on: ubuntu-latest
defaults:
run:
working-directory: apps/web
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm run lint
- run: npm run build
✅ (3) 統合
CIの最終目的は「PRをマージする前に安全確認」。
GitHubの設定で：
- PRのチェックが通らないとマージできない
- mainにpushされたらCDを起動する
これで、テスト失敗コードのマージ防止が自動化されます。
🚀 2. CD：デプロイ自動化フェーズ
「mainにマージされたら自動で本番・検証環境にデプロイ」
📦 (1) Dockerで環境統一
YAML内でPythonやNodeを個別セットアップしてもよいですが、
チーム運用・本番移行を見据えるならDockerで統一環境を作ります。
例: Dockerfile
# apps/api/Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install fastapi uvicorn pydantic
CMD ["uvicorn", "apps.api.main:app", "--host", "0.0.0.0", "--port", "8000"]
これで「どのマシンでも同じ環境で起動」が保証されます。
☁️ (2) CDの流れ
例: Render / Fly.io / Railway / Vercel
mainブランチにマージ → ActionsがDockerイメージをビルド →
GitHub Container Registry (GHCR) にpush → RenderやFly.ioがpullしてデプロイ。
YAMLイメージ
# .github/workflows/cd.yml
name: CD (Deploy)
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Login to GHCR
run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
- name: Build Docker image
run: docker build -t ghcr.io/${{ github.repository }}/memo-api:latest .
- name: Push Docker image
run: docker push ghcr.io/${{ github.repository }}/memo-api:latest
⚙️ ポイント
- Secrets に
DEPLOY_API_KEYやFLY_API_TOKENを設定- デプロイ環境 (
production) は承認ステップを設けるのも良い
🧱 3. CI/CD連携の構成まとめ
.github/workflows/
├── backend-ci.yml # FastAPIテスト
├── frontend-ci.yml # Next.js Lint/Build
└── cd.yml # Dockerビルド & デプロイ
CIが開発の品質を守り、CDがリリースを自動化する構造。
🧩 4. チーム開発時のメリット
| 項目 | 手動の場合 | CI/CD導入後 |
|---|---|---|
| テスト | 各自ローカル実行 | push時に自動実行 |
| デプロイ | 手動で再起動・FTP等 | mainマージで自動反映 |
| エラー検出 | リリース後気づく | PR時に検出 |
| 一貫性 | 各自の環境依存 | Dockerで統一 |
| 品質保証 | 個人に依存 | システムで担保 |
🧭 5. 新卒エンジニアが理解すべき軸
| 概念 | 目的 | 例 |
|---|---|---|
| CI | テスト自動化 | pytest, lint |
| CD | デプロイ自動化 | Render/Vercel |
| YAML | 処理手順の定義 | .github/workflows/*.yml |
| Secrets | 機密情報 | APIキーやトークン |
| Docker | 環境の統一化 | 再現性・移植性UP |
✅ 次のステップ提案
あなたの構成に合わせて、次の段階で以下を整備するのが理想です：
| ステップ | 内容 |
|---|---|
| ① |
.github/workflows/backend-ci.yml を作る（pytest通るまで） |
| ② |
.github/workflows/frontend-ci.yml を作る（lint/build） |
| ③ |
.github/workflows/cd.yml を作る（mainでDocker push） |
| ④ | Render/Fly.ioを接続して自動デプロイ完成 |