ブランチ戦略・デプロイメント

目的: ソースコードのバージョン管理とデプロイメントのプロセスを明確化し、複数の開発者が並行して作業できる環境を整備しながら、本番環境への安全かつ効率的なリリースを実現する
スコープ: ブランチモデルの選定、ブランチ運用フロー、コミット規約、デプロイメント戦略、環境管理をカバーする。個別のCI/CDツールの詳細設定は対象外
推奨する実施タイミング: プロジェクト開始時、開発環境構築と並行して実施する
関連するステークホルダー: 開発チームリーダー、開発者、インフラチーム、プロジェクトマネージャー、品質保証チーム

📥 重要な前提知識・インプット

前提知識: Git の基本操作、ブランチモデル(Git Flow、GitHub Flow等)の理解、CI/CD の基礎知識、リリース管理の概念
インプット: 開発体制(チーム規模、スキルレベル)、リリース頻度・計画、デプロイ環境構成、CI/CDツールの選定状況

📄 成果物の定義

ドキュメントテンプレート: 📄[テンプレ]ブランチ戦略・デプロイメント
必須要素: ブランチモデル定義書、ブランチ運用フロー図、コミットメッセージ規約、デプロイメントフロー図、環境別デプロイ方式一覧、ロールバック手順書

✅ 品質基準・レビュー観点

✅ 品質チェックリスト:

チェック項目	チェック内容
ブランチモデルの適切性	チーム規模・リリース頻度に適したモデルが選定されているか
運用フローの明確性	各ブランチの作成・マージ手順が明確に定義されているか
デプロイの自動化	手動作業を最小限にした自動デプロイの仕組みがあるか
ロールバック手順	緊急時のロールバック手順が明確で実行可能か
環境管理の整合性	各環境の構成・変数管理方法が統一されているか

👁️‍🗨️ レビュー観点:

開発体制との整合性: チーム規模・スキルレベルに適した複雑度のブランチモデルか
リリース計画との整合性: リリース頻度・サイクルに適したデプロイメント戦略か
安全性の確保: 本番環境への誤デプロイを防ぐ承認プロセスがあるか
運用性の考慮: 障害時の迅速なロールバック、デプロイ履歴の追跡が可能か
自動化の範囲: 人的ミスを防ぐための適切な自動化レベルか

🧪成果物のサンプル

# ブランチ戦略・デプロイメント

## 採用ブランチモデル

### 採用モデル: Git Flow

本プロジェクトでは **Git Flow** モデルを採用する。

### 採用背景・目的

**背景:**
- 複数機能の並行開発が必要
- 本番環境への影響を最小限に抑えたい
- リリースサイクルが計画的（2週間〜1ヶ月ごと）
- 緊急バグ修正への迅速な対応が必要

**目的:**
- **品質管理**: リリース前の十分なテスト期間を確保
- **並行開発**: 複数の機能開発を独立して進行
- **安定性**: 本番ブランチ(main)の安定性を維持
- **トレーサビリティ**: リリースバージョンとコードの対応を明確化
- **緊急対応**: ホットフィックスによる迅速な本番修正

```mermaid
gitGraph
    commit
    branch develop
    checkout develop
    commit
    branch feature/login
    checkout feature/login
    commit
    commit
    checkout develop
    merge feature/login
    branch release/v1.0
    checkout release/v1.0
    commit
    checkout main
    merge release/v1.0 tag: "v1.0.0"
    checkout develop
    merge release/v1.0
```

## ブランチ種別と役割

| ブランチ種別 | 命名規則 | 役割 | 派生元 | マージ先 |
|------------|---------|------|--------|---------|
| main | `main` | 本番環境リリース用 | - | - |
| develop | `develop` | 開発用の最新コード | main | main（リリース時） |
| feature | `feature/機能名` | 機能開発 | develop | develop |
| release | `release/バージョン` | リリース準備 | develop | main, develop |
| hotfix | `hotfix/修正内容` | 緊急バグ修正 | main | main, develop |

## ブランチ運用フロー

### 機能開発フロー
```mermaid
graph LR
    A[develop] -->|作成| B[feature/xxx]
    B -->|開発| C[コミット]
    C -->|PR作成| D[コードレビュー]
    D -->|承認| E[developへマージ]
    E --> F[ブランチ削除]
```

1. developブランチから feature ブランチを作成
2. 機能開発を実施
3. プルリクエスト作成、コードレビュー実施
4. レビュー承認後、developへマージ
5. featureブランチを削除

### リリースフロー
1. developブランチから release ブランチを作成
2. リリース準備作業（バージョン番号更新、軽微な修正）
3. テスト実施
4. mainブランチへマージし、タグ付け
5. developブランチへもマージ
6. releaseブランチを削除

### ホットフィックスフロー
1. mainブランチから hotfix ブランチを作成
2. 緊急修正を実施
3. mainブランチへマージし、タグ付け
4. developブランチへもマージ
5. hotfixブランチを削除

## 8.2.4 コミットメッセージ規約

Conventional Commits形式を採用する。

**フォーマット:**
```
<type>(<scope>): <subject>

<body>

<footer>
```

**type の種類:**
- `feat`: 新機能
- `fix`: バグ修正
- `docs`: ドキュメント変更
- `style`: コードスタイル変更（機能に影響なし）
- `refactor`: リファクタリング
- `test`: テストコード追加・修正
- `chore`: ビルドプロセスやツールの変更

**例:**
```
feat(auth): ユーザーログイン機能を追加

- JWTトークンによる認証を実装
- ログイン画面のUI作成
- セッション管理機能の追加

Closes #123
```

---

## デロイメント戦略

### フロー設計の背景・目的

**背景:**
- 各環境での検証ステップが必要
- 本番環境への影響を最小限に抑えたい
- デプロイ頻度が高い（週1回以上）
- 人的ミスを防止したい

**目的:**
- **段階的検証**: 開発→ステージング→本番の順で段階的に検証
- **自動化**: 人的ミスの削減と効率化
- **安全性**: 本番デプロイ前の承認プロセス
- **迅速性**: 開発環境への即座の反映
- **トレーサビリティ**: デプロイ履歴の記録

### デプロイメントフロー

```mermaid
graph TD
    A[開発完了] --> B[developブランチ]
    B -->|自動デプロイ| C[開発環境]
    B --> D[releaseブランチ作成]
    D -->|自動デプロイ| E[ステージング環境]
    E --> F[テスト・検証]
    F -->|承認| G[mainブランチへマージ]
    G -->|手動承認後| H[本番環境デプロイ]
```

### 環境別デプロイ方式

| 環境 | トリガー | 承認 | デプロイ方式 | 目的 |
|------|---------|------|-------------|------|
| 開発環境 | developへのマージ | 不要 | 自動デプロイ | 迅速なフィードバック |
| ステージング環境 | releaseブランチ作成 | 不要 | 自動デプロイ | 本番同等環境での検証 |
| 本番環境 | mainへのマージ | 必要 | 手動承認後自動デプロイ | 安全性の確保 |

### ロールバック手順

本番環境で問題が発生した場合の緊急ロールバック手順:

1. 前バージョンのタグを確認
2. デプロイツールから前バージョンを選択
3. ロールバック実行
4. 動作確認
5. インシデント報告書作成

**例: AWS CodeDeployでのロールバック**
```bash
aws deploy stop-deployment --deployment-id d-XXXXXXXXX
aws deploy create-deployment \
  --application-name myapp \
  --deployment-group-name production \
  --s3-location bucket=myapp-deploy,key=v1.0.0.zip,bundleType=zip
```

### デプロイ時チェックリスト

- [ ] テストがすべて成功しているか
- [ ] マイグレーションスクリプトの確認
- [ ] 環境変数の設定確認
- [ ] ロールバック手順の確認
- [ ] 監視・アラート設定の確認
- [ ] ステークホルダーへの通知
- [ ] デプロイ後の動作確認項目の準備

---

## 環境管理

### 環境構成

```mermaid
graph TB
    subgraph 開発環境
    D1[開発者PC]
    D2[共有開発サーバー]
    end
    
    subgraph ステージング環境
    S1[Webサーバー]
    S2[DBサーバー]
    end
    
    subgraph 本番環境
    P1[Webサーバー]
    P2[DBサーバー]
    P3[キャッシュサーバー]
    end
    
    D1 --> D2
    D2 --> S1
    S1 --> P1
```

### 環境変数管理

| 環境 | 管理方法 | 設定ファイル |
|------|---------|-------------|
| ローカル | `.env.local` | Git管理外 |
| 開発 | AWS Parameter Store | IaCで管理 |
| ステージング | AWS Secrets Manager | IaCで管理 |
| 本番 | AWS Secrets Manager | IaCで管理 |

### データベース管理

- マイグレーションツール: Flyway / Liquibase
- バージョン管理: すべてのスキーマ変更をマイグレーションスクリプトで管理
- 適用順序: 開発環境 → ステージング環境 → 本番環境

🔄 設計の進め方・プロセス

🏗️ プロセス1: ブランチモデルの選定

設計対象:

プロジェクトの特性に合わせて、採用するブランチモデルを選定する。

具体例:

Git Flow、GitHub Flow、GitLab Flow、Trunk-Based Development のいずれを採用するか
main/develop/feature/release/hotfix などのブランチ種別をどう定義するか
ブランチの命名規則をどうするか(例: feature/機能名、release/v1.0.0)
どのブランチからどのブランチへマージするかのフローを決める

設計原則:

チーム規模との整合: 小規模チームには GitHub Flow のようなシンプルなモデル、大規模には Git Flow のような構造化されたモデルを選ぶ
リリース頻度との適合: 高頻度リリース(日次・週次)なら GitHub Flow、計画的リリース(月次)なら Git Flow が適している
複雑さの最小化: チームのスキルレベルに応じて、過度に複雑でない運用可能なモデルを選定する
並行開発の考慮: 複数機能の並行開発が必要な場合は、feature ブランチでの独立開発を前提とする
緊急対応の想定: 本番環境の緊急バグ修正に対応できる hotfix フローを用意する

文書化の推奨表現:

モデル選定の根拠: なぜそのブランチモデルを選んだのか、プロジェクト特性との関係を明記する
ブランチ種別一覧: 各ブランチの役割、派生元、マージ先を表形式で整理する
フロー図の作成: Mermaid などで視覚的にブランチの作成・マージフローを表現する
命名規則の明示: ブランチ名のフォーマットと具体例を記載する

🏗️ プロセス2: コミットメッセージ規約の策定

設計対象:

チーム全体で統一されたコミットメッセージのフォーマットを定義する。

具体例:

Conventional Commits 形式を採用するか、独自形式を定義するか
type(feat/fix/docs など)の種類をどう定義するか
scope(対象モジュール・機能)をどのように記述するか
コミットメッセージの言語(日本語/英語)をどうするか

設計原則:

標準形式の採用: Conventional Commits など業界標準の形式を採用し、ツール連携を容易にする
明確な分類: type を適切に分類し、変更内容が一目で分かるようにする
トレーサビリティの確保: 課題管理ツールのチケット番号を記載し、変更理由を追跡可能にする
自動化への対応: コミットメッセージから自動的にリリースノートを生成できる形式を採用する

文書化の推奨表現:

フォーマットの定義: コミットメッセージの構造(type/scope/subject/body/footer)を明記する
type 一覧の整備: 各 type の意味と使用例を一覧表で示す
良い例・悪い例: 具体的なコミットメッセージの例を示し、チームの理解を促進する

🏗️ プロセス3: デプロイメント戦略の策定

設計対象:

各環境へのデプロイメントフロー、トリガー、承認プロセスを決定する。

具体例:

開発環境・ステージング環境・本番環境へのデプロイタイミングをどう設定するか
どのブランチのマージをトリガーとして自動デプロイするか
本番環境デプロイに承認プロセスを設けるか
ロールバック手順をどう定義するか

設計原則:

段階的検証: 開発→ステージング→本番の順で段階的に検証し、本番環境へのリスクを最小化する
自動化の推進: 人的ミスを防ぐため、可能な限りデプロイを自動化する
安全性の確保: 本番環境へのデプロイには手動承認を設け、意図しないデプロイを防止する
迅速なフィードバック: 開発環境への自動デプロイで開発者に迅速なフィードバックを提供する
ロールバック可能性: 問題発生時に迅速にロールバックできる手順を用意する

文書化の推奨表現:

デプロイフロー図: 各環境へのデプロイの流れを視覚的に表現する
環境別デプロイ方式一覧: 各環境のトリガー、承認有無、デプロイ方式を表形式で整理する
ロールバック手順書: 緊急時の具体的なロールバック手順をステップバイステップで記載する
デプロイ時チェックリスト: デプロイ前に確認すべき項目をリスト化する

🏗️ プロセス4: 環境管理の定義

設計対象:

開発・ステージング・本番の各環境の構成と、環境変数・シークレットの管理方法を定義する。

具体例:

各環境のサーバー構成をどうするか(単一サーバー/冗長化構成)
環境変数をどこで管理するか(.env ファイル/AWS Parameter Store/Secrets Manager)
データベースのマイグレーション管理をどうするか(Flyway/Liquibase)
環境間でのデータ同期をどう扱うか

設計原則:

環境の独立性: 各環境は独立して動作し、相互に影響を与えないようにする
本番環境の忠実性: ステージング環境は本番環境と同等の構成とし、検証精度を高める
シークレット管理の厳格化: パスワード・APIキーなどはコードに含めず、専用の管理ツールで保護する
Infrastructure as Code: 環境構成はコード化し、バージョン管理・再現性を確保する

文書化の推奨表現:

環境構成図: 各環境のサーバー・ネットワーク構成を図示する
環境変数管理方針: 各環境での環境変数の管理方法を一覧表で整理する
マイグレーション管理: データベーススキーマ変更の管理方法とツールを明記する

🚨 よくある失敗と予防策　

🚧 実例収集後、追記予定

📚 参考資料・関連リンク

参考文献: 『継続的デリバリー』(Jez Humble)、『Accelerate』(Nicole Forsgren ほか)、Atlassian Git チュートリアル
関連する他のガイド: CI/CD構築ガイド、環境構築ガイド、リリース管理ガイド、インフラ設計ガイド
ツール・テンプレート: Git Flow チートシート、GitHub Actions ワークフローテンプレート、デプロイチェックリストテンプレート
外部リンク:

テンプレートサイト: 📄テンプレート集