目次

• リアル大学生
  • 目次
  • リンク一覧
  • 使用技術
  • アーキテクチャ
  • 環境構築
  • スポンサー記事
  • Storybook
  • Terraform
  • テスト
  • OneSignalテスト通知
  • ディレクトリ構成
  • Gitの運用
    • ブランチ
    • コミットメッセージの記法

リンク一覧

• リアル大学生
• Storybook

(トップへ)

使用技術

Category	Technology Stack
Frontend	Next.js, React, TypeScript, Tailwind CSS
Backend	Go, Vercel Functions
CMS	microCMS, Zenn RSS
Infrastructure	Cloudflare Pages, Vercel, Amazon S3, Terraform
Environment setup	Node.js, pnpm, Docker Compose
CI/CD	GitHub Actions, Chromatic, CodeQL, Dependabot
Design	Storybook, Canva
Google	AdSense, Analytics, Search Console, reCAPTCHA
Integrations	PWA, OneSignal, Sentry, Iframely, Instagram

(トップへ)

アーキテクチャ

(トップへ)

環境構築

Node.jsは.nvmrc、pnpmはpackage.jsonのpackageManagerに記載されたバージョンを使用する。通常はフロントエンドをホスト上、Go APIをDocker上で起動する。docker-compose.ymlのjsサービスは、フロントエンドもコンテナで起動したい場合の代替手段として利用できる。

# リポジトリのクローン
git clone git@github.com:Arata1202/NextBlogApp.git
cd NextBlogApp

# .env.exampleから.envを作成
cp .env.example .env

# 利用する機能に必要な環境変数を設定
vi .env

# フロントエンドの依存関係をインストール
corepack enable
pnpm install --frozen-lockfile

# Go APIをDockerで起動
docker compose up -d --build go

# フロントエンドをホスト上で起動
pnpm dev

ブラウザで http://localhost:3000 にアクセスする。ローカルのGo APIをフロントエンドから利用する場合は、.envに次のURLを設定する。

NEXT_PUBLIC_API_SEARCH_URL=http://localhost:8000/api/search
NEXT_PUBLIC_API_SENDEMAIL_URL=http://localhost:8000/api/sendemail

# Go APIを停止
docker compose down

(トップへ)

スポンサー記事

microCMSのblog APIに以下のフィールドを追加する。

フィールドID	種類	設定
isSponsored	真偽値	初期値をfalseにする
sponsorUrl	テキスト	広告主の公式URL

isSponsoredを有効にした記事では、一覧と記事上部にPR表示が追加され、記事上部に「本記事は、広告主から依頼を受けて制作した広告です。」と表示される。本文中のリンクは、sponsorUrlと同じドメインまたはそのサブドメインに限りrel="sponsored"が付与される。

スポンサー記事では有効なsponsorUrlが必須となり、不足している場合はビルドが失敗する。

スポンサー記事は、初回公開時のOneSignalプッシュ通知から自動的に除外される。

(トップへ)

Storybook

共通UIと主要な表示状態はStorybookで確認する。ツールバーからLight／Darkテーマを切り替えられ、AccessibilityパネルとブラウザテストでWCAG違反や操作を検証できる。

# Storybookを起動
pnpm storybook

# 静的Storybookを生成
pnpm build-storybook

# Chromiumをインストール（初回またはPlaywright更新後）
pnpm exec playwright install chromium

# StoryとアクセシビリティをChromiumで検証
pnpm test:storybook

Storyは対象コンポーネントと同じディレクトリのindex.stories.tsxへ配置する。基礎スタイルと共通fixtureはsrc/stories/で管理する。

(トップへ)

Terraform

# Terraformディレクトリへ移動
cd terraform

# terraform.tfvars.exampleからterraform.tfvarsを作成
cp terraform.tfvars.example terraform.tfvars

# terraform.tfvarsの編集
vi terraform.tfvars

# Terraformの初期化
terraform init

# 変更内容の確認
terraform plan

# AWSリソースの作成・更新
terraform apply

(トップへ)

テスト

# Lint / 型チェック / ユニットテスト
pnpm lint
pnpm typecheck
pnpm test:run

# Storybookの静的ビルド / ブラウザテスト
pnpm build-storybook
pnpm test:storybook

# Goの静的解析 / テスト（Docker）
docker compose run --rm go go vet ./...
docker compose run --rm go go test ./...

# Playwright のブラウザをインストール
pnpm exec playwright install chromium

# E2Eテスト（固定データのビルドとテストサーバーの起動を含む）
pnpm test:e2e

# E2Eテストをブラウザ表示ありで実行
pnpm test:e2e:headed

# E2Eレポートを表示
pnpm test:e2e:report

(トップへ)

OneSignalテスト通知

GitHub ActionsのOneSignal Test Notificationから、Test Usersセグメントへブログ／Zenn × Web／iOSの4種類のテスト通知を送信できる。

事前にGitHubのonesignal-test Environmentを作成し、Deployment branches and tagsをmasterのみに制限したうえで、次のSecretsを登録する。必要に応じてEnvironmentにRequired reviewersも設定する。

• ONESIGNAL_APP_ID
• ONESIGNAL_REST_API_KEY

ActionsのRun workflowでは、ペイロードだけを表示するdry-runが既定値になっている。実際に通知するときだけmasterブランチでsendを選択する。master以外からの送信指定はワークフローを失敗させる。送信先セグメントはスクリプト内でTest Usersに固定している。

ローカルでは次のコマンドで同じテストを実行できる。

# ペイロードの確認（--dry-runは省略可）
scripts/send-onesignal-test-notifications.sh

# Test Usersへ送信
scripts/send-onesignal-test-notifications.sh --send

(トップへ)

ディレクトリ構成

.
├── .github/workflows/  # CI/CD・運用ワークフロー
├── .storybook/         # Storybook設定
├── api/                # Vercel Functionsのエントリーポイント
├── cmd/                # ローカルGo APIサーバー
├── docker/             # 開発用Dockerイメージ
├── docs/                # READMEなどのドキュメント資産
├── e2e/                 # Playwright E2Eテスト
├── pkg/api/             # Go APIの実装
├── public/              # 静的ファイル
├── scripts/             # E2E・運用スクリプト
├── src/
│   ├── app/             # Next.js App Router
│   ├── components/      # UIコンポーネント
│   ├── stories/         # 基礎スタイル・共通Story fixture
│   ├── config/          # 環境変数の参照
│   ├── contents/        # 固定ページのコンテンツ
│   ├── hooks/           # React Hooks
│   ├── libs/            # データ取得・変換
│   ├── styles/          # グローバルスタイル・共通UI定義
│   ├── types/           # TypeScriptの型定義
│   └── utils/           # 汎用処理
└── terraform/           # AWSリソース定義

(トップへ)

Gitの運用

ブランチ

GitHub Flowを使用する。 masterとfeatureブランチで運用する。

ブランチ名	役割	派生元	マージ先
master	本番環境	-	-
feature/*	機能開発	master	master

コミットメッセージの記法

fix: バグ修正
feat: 新機能追加
perf: パフォーマンス改善
refactor: コードのリファクタリング
docs: ドキュメントのみの変更
style: コードのフォーマットに関する変更
test: テストコードの変更
build: ビルドシステムや依存関係の変更
ci: CI/CD設定の変更
revert: 変更の取り消し
chore: その他の変更

(トップへ)