コンテンツにスキップ

02. リリースプロセス

このドキュメントは、開発された成果物を新しいバージョンとしてリリースするための、具体的な手順（ワークフロー）を定めます。このプロセスに従うことで、誰でも安全で一貫性のあるリリース作業を実施できます。

1. リリースの種類

リリースは、大きく分けて2種類あります。

  • 計画的リリース (メジャー / マイナー):
    • mainブランチで開発された新機能群を、計画的にリリースします。このドキュメントでは、主にこのプロセスについて詳述します。
  • Hotfixリリース (パッチ):
    • releaseブランチで発見された緊急のバグを修正するための、計画外のリリースです。基本的な流れは05_ブランチ規定で定義されていますが、このドキュメントの関連ステップも適用されます。

2. 計画的リリースのプロセス

計画的なリリースは、以下のステップで慎重に行います。

sequenceDiagram
    participant dev as Developer
    participant main as main (開発版)
    participant release_branch as release/v1.1.0
    participant stable_release as release (安定版)

    dev->>main: 1. mainからリリースブランチを作成
    activate release_branch
    dev->>release_branch: 2. バージョン更新, CHANGELOG生成など最終準備
    Note over release_branch: 3. 最終レビューと承認

    dev->>stable_release: 4. PR: release/v1.1.0 → release
    Note over stable_release: マージ
    dev->>stable_release: 5. v1.1.0タグを作成＆プッシュ

    dev->>main: 6. PR: release/v1.1.0 → main
    Note over main: マージバック

    dev-->>release_branch: 7. リリースブランチを削除

    Note right of dev: 8. 成果物を公開

Step 1: リリースブランチの作成

  • mainブランチの最新の状態から、リリース作業専用のブランチを作成します。

  • 命名規則: release/v[バージョン番号] (例: release/v1.1.0)

    git checkout main
git pull origin main
git checkout -b release/v1.1.0
git push origin release/v1.1.0

Step 2: リリースブランチでの最終準備

リリースブランチ上では、リリースに直接関連する作業のみを行います。

  1. バージョン番号の更新:
    • 01_バージョン管理規定に従い、プロジェクトのバージョン番号を確定させます。（例: .csprojやpackage.jsonのバージョンを1.1.0に更新）
  2. 変更履歴 (CHANGELOG) の生成:
  3. ドキュメントの更新:
    • READMEやAPI仕様書など、今回のリリース内容に関連するドキュメントを最終確認し、必要であれば更新します。
  4. コミット:
    • 上記の変更を、一つのコミットにまとめてプッシュします。
    • コミットメッセージ例: chore(release): prepare for v1.1.0

Step 3: 最終レビューと承認

  • リリースブランチ（release/v1.1.0）から、releaseブランチとmainブランチの両方に対するプルリクエストを作成し、ドラフト状態にしておきます。
  • このリリースブランチを使い、ステージング環境などで最終的な動作確認や受け入れテストを実施します。
  • 全てのテストが完了し、リリースしても問題ないと判断されたら、関係者から承認を得ます。

Step 4: releaseブランチへのマージ（安定版の更新）

  • release/v1.1.0 → release へのプルリクエストをレビューし、マージします。
  • マージ方法: mainブランチとは異なり、こちらは通常のMerge commitを推奨します。これにより、「バージョンv1.1.0のリリース」という事実がマージコミットとして明確に履歴に残ります。

Step 5: Gitタグの作成とプッシュ

  • releaseブランチにマージされた直後のコミットに対して、バージョンタグを付与し、リモートリポジトリにプッシュします。

    git checkout release
git pull origin release
git tag -a v1.1.0 -m "Release version 1.1.0"
git push origin v1.1.0

Step 6: mainブランチへのマージバック

  • release/v1.1.0 → main へのプルリクエストをレビューし、マージします。
  • これにより、バージョン番号の更新やCHANGELOG.mdの内容が、開発ブランチにも反映されます。

Step 7: リリースブランチの削除

  • 両方のブランチへのマージが完了したら、役目を終えたリリースブランチ（release/v1.1.0）を削除します。

Step 8: 成果物の公開

  • Gitタグの作成をトリガーとして、CI/CDパイプラインが自動的に成果物（パッケージ、Dockerイメージなど）をビルドし、適切な場所（NuGet, Docker Hub, etc.）に公開します。
  • 04_リリースノートの作成.mdに従い、GitHub Releasesなどでユーザー向けのリリースノートを公開します。