[テンプレ]ブランチ戦略・デプロイメント

テンプレート

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

## 採用ブランチモデル

### 採用モデル: 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
- バージョン管理: すべてのスキーマ変更をマイグレーションスクリプトで管理
- 適用順序: 開発環境 → ステージング環境 → 本番環境

プレビュー

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

採用ブランチモデル

採用モデル: Git Flow

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

採用背景・目的

背景:

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

目的:

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

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

ブランチ運用フロー

機能開発フロー

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

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

リリースフロー

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

ホットフィックスフロー

mainブランチから hotfix ブランチを作成
緊急修正を実施
mainブランチへマージし、タグ付け
developブランチへもマージ
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回以上）
人的ミスを防止したい

目的:

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

デプロイメントフロー

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

環境別デプロイ方式

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

ロールバック手順

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

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

例: AWS CodeDeployでのロールバック

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

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

テストがすべて成功しているか

マイグレーションスクリプトの確認

環境変数の設定確認

ロールバック手順の確認

監視・アラート設定の確認

ステークホルダーへの通知

デプロイ後の動作確認項目の準備

環境管理

環境構成

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
バージョン管理: すべてのスキーマ変更をマイグレーションスクリプトで管理
適用順序: 開発環境 → ステージング環境 → 本番環境