シンプルなreleaseブランチ運用についてのまとめ（2012/11/27版）

1. はじめての
RELEASEブランチ運用
（SVN編）
高野将

2. コンテキスト
 VCSはSubversion
 大勢の開発メンバーがバシバシ開発、バグ修正
 モジュール単位で随時リリースする必要あり

3. 運用ルール策定
「いつ？」、「何を？」、「どのように？」リリース
するか

4. いつ？
 最も頻繁でも日次でリリースする
 これを超えると、リリース作業のコストが高すぎる
 リリースしたモジュール管理できるの？
 どのバグが直った？
 どのフィーチャーが実装されている？
 リリース作業の負荷は高い
 モジュール選定
 出荷可能かどうか判定
 必要なファイルのみ取り出す
 単純なファイルコピー、アーカイブの時間

5. 何を？
 開発チームで選定する
 リリースするモジュールの状態（実現できたフィー
チャー、修正したバグ）を開発チームで管理する
 開発チームの代表者がリリースモジュールを選定す
る
 サブチームに分かれていれば、サブチームごとに代表者
が取りまとめる
 中途半端な状態の物はリリースしない
 最低でもコンパイルが通るものを

6. どのように？
 releaseブランチを活用する
 releaseブランチのソース＝リリース先のソースとなる
よう同期を取る
 開発メイン（trunk）からリリース対象モジュールをマー
ジする
 リリース先の環境に合わせてカスタマイズする

7. releaseブランチ
Subversionでのreleaseブランチ運用

8. releaseブランチ運用イメージ
trunk A D E F H J K L
release B C G I M N

9. releaseブランチ作成
 trunkをコピーしてreleaseブランチを作成する
 SVNはリポジトリー内の通しリビジョンなのでrelease
ブランチ作成でもリビジョン番号が付加される
trunk A
release B

10. リリース先向けカスタマイズ
 リリース先に合わせた変更をreleaseブランチにコ
ミットする
 ファイルパス、URL、環境変数、etc...
 この段階でリリースが可能になる
 リリースブランチをエクスポートするだけ
trunk A
release B C

11. 開発が進む
 開発ブランチであるtrunkにコミットされる
 releaseブランチは変更されない
trunk A D E F
release B C

12. releaseブランチへのマージ
 trunkの変更を、「対象モジュール単位」でrelease
ブランチにマージする
 Subversionのマージ機能を活用する
 releaseブランチでは、trunkの複数コミットがまと
められてコミットされるイメージになる
trunk A D E F
release B C G

13. trunk、releaseブランチの成長
 対象モジュールは開発チームが選定するため、
trunkのコミット内容とreleaseブランチへの反映が
前後することもある
trunk A D E F H J K L
release B C G I M N

14. releaseブランチの利点
 開発を止める必要がない
 trunkとreleaseはそれぞれ別々に成長する
 trunkが壊れてもreleaseには影響しない
 リリース先に合わせたカスタマイズは初回のみで良い
 リリース環境が複数あるなら、それぞれに対するブランチ
を作成するだけ
 リリース先のコードがすぐに参照可能
 ただし、正しく同期を行うことが大切
 リリース先でコード修正は原則としてしない
 修正したら即座にreleaseブランチに反映し、trunkに逆マージす
る

15. まとめ

16. まとめ
 リリース作業は日次で区切り、リリース対象機能
の状態を管理して行う
 リリース作業はreleaseブランチを用いた運用を行
う
 releaseブランチではリリース先に合わせたカスタ
マイズを行う
 releaseブランチへはリリース対象モジュール単位
にtrunkからマージする
 リリースブランチへのマージはVCSの機能で行う