ブランチ戦略

main (master)  ← 本番。常にデプロイ可能
  └─ feature/*  ← 短命ブランチ (数日以内にマージ)
  • main (master): 本番ブランチ。PR経由でのみマージ
  • feature/xxx: 機能・修正ブランチ。main から切り、完了後すぐマージ・削除

環境構成 (2環境)

環境ブランチGASプロジェクトスプレッドシート
Prodmain本番用GAS本番スプシ
Devfeature/* (全て共有)開発用GAS開発用スプシ

feature ブランチごとにスプシを作るのではなく、全 feature ブランチが1つの開発環境を共有する。

初期セットアップ

1. 開発用スプレッドシートの作成

  1. 本番スプレッドシートを「コピーを作成」
  2. コピーしたスプシのIDを控える(URLの /d//edit の間の文字列)

2. 開発用GASプロジェクトの作成

  1. script.google.com で新規プロジェクト作成
  2. スクリプトIDを控える(プロジェクトの設定 → スクリプトID)

3. clasp設定ファイルの作成

# テンプレートからコピー
cp .clasp.dev.json.example  .clasp.dev.json
cp .clasp.prod.json.example .clasp.prod.json

# 各ファイルの scriptId を実際のIDに書き換え

4. GASスクリプトプロパティの設定

各GASプロジェクトの「プロジェクトの設定 → スクリプトプロパティ」で以下を設定:

プロパティ名説明備考
ENVprod または dev未設定時は prod 扱い
SPREADSHEET_ID対象スプレッドシートID環境ごとに異なるID
GEMINI_API_KEYGemini APIキーDev/Prod共通でも可
RECEIPT_FOLDER_ID領収書フォルダID任意

日常の開発フロー

feature ブランチでの作業

# 1. ブランチ作成
git checkout main && git pull
git checkout -b feature/my-change

# 2. コード修正

# 3. 開発GASへデプロイ & 動作確認
npm run push:dev
# → ブラウザで開発スプシを開いて動作確認

# 4. コミット & プッシュ
git add <files>
git commit -m "feat: ..."
git push origin feature/my-change

# 5. PR作成 → レビュー → main へマージ

本番デプロイ

main へのマージ後、GitHub Actions が自動デプロイ。 手動で本番GASへ反映する場合:

git checkout main && git pull
npm run push:prod

npm スクリプト一覧

コマンド説明
npm run switch:devclasp の接続先を開発GASに切替
npm run switch:prodclasp の接続先を本番GASに切替
npm run push:dev開発GASへデプロイ
npm run push:prod本番GASへデプロイ

環境判定 (コード内)

001_env.jsEnv オブジェクトで現在の環境を判定できる:

if (Env.isDev()) {
  // 開発環境のみの処理
}

Env.log('処理開始');  // → [DEV] 処理開始 or [PROD] 処理開始

UC スライス開発との連携 (ADR-0021 / ADR-0025 / ADR-0028 / ADR-0029)

Walking Skeleton 方式でスライスを実装する際は、以下のルールを追加する。

3 原則(必須)

#ルール根拠
1短命ブランチ ≤ 2 日: feature ブランチの寿命は最長 2 日トランクベース開発のコアプラクティス
21 PR = 1 UC スライス: 1 つの PR には必ず 1 UC スライス分の実装のみADR-0029 C1-C6 の 1 PR 原則
3slice_id PR 必須欄: PR 説明文に slice_id: UC-{N}-S{NN} を必ず記載ADR-0026 自動同期の前提条件

ブランチ命名

feature/uc{N}-s{NN}-<slug>   # 例: feature/uc4-s01-ingest-bank-csv

slice_idUC-{N}-S{NN} 形式)を含めることで sync_slice_id.yml が自動的に todo_master_tables.md の対応行を更新する。

PR タイトル

feat(UC-4-S01): 銀行 CSV インポート Walking Skeleton

GitHub Actions sync_slice_id.yml が PR タイトルの UC-{N}-S{NN} パターンを検出し、usecase_dev_mapping.mdwalking_skeleton_status を自動更新する。

walking_skeleton_status の遷移

status意味更新タイミング
pending未着手初期状態
skeletonWalking Skeleton 4 要素が貫通テスト(Input→Output→Log→Error の 4 点確認)後に手動更新
in_progress肉付け実装中skeleton 完了後
done完了PR マージ後に sync_slice_id.yml が自動更新

now_next_later の運用

  • Now: 現在 WIP のスライス(同時 1 件原則)
  • Next: 次に着手するスライス(優先キュー)
  • Later: バックログ(着手時期未定)

usecase_dev_mapping.mdnow_next_later 列を更新する担当は doc スペース。GAS 実装完了後に doc 側が手動で in_progress → done の確認と列更新を行う。

注意事項

  • Dev環境は全featureブランチで共有するため、同時に複数人が push すると上書きされる。個人開発なら問題なし
  • 動作未確認のコードをGitHubに push しない(push:dev で確認してから git push
  • .clasp.*.json.gitignore 対象。IDは各開発者がローカルで管理