はじめての RELEASEブランチ運用 （SVN編）

高野将

コンテキスト

VCSはSubversion

大勢の開発メンバーがバシバシ開発、バグ修正

モジュール単位で随時リリースする必要あり

「いつ？」、「何を？」、「どのように？」リリースするか

運用ルール策定

いつ？

最も頻繁でも日次でリリースする

これを超えると、リリース作業のコストが高すぎる

リリースしたモジュール管理できるの？ どのバグが直った？

どのフィーチャーが実装されている？

リリース作業の負荷は高い モジュール選定

出荷可能かどうか判定

必要なファイルのみ取り出す

単純なファイルコピー、アーカイブの時間

何を？

開発チームで選定する

リリースするモジュールの状態（実現できたフィーチャー、修正したバグ）を開発チームで管理する

開発チームの代表者がリリースモジュールを選定する

サブチームに分かれていれば、サブチームごとに代表者が取りまとめる

中途半端な状態の物はリリースしない

最低でもコンパイルが通るものを

どのように？

releaseブランチを活用する

releaseブランチのソース＝リリース先のソースとなるよう同期を取る

開発メイン（trunk）からリリース対象モジュールをマージする

リリース先の環境に合わせてカスタマイズする

Subversionでのreleaseブランチ運用

releaseブランチ

releaseブランチ運用イメージ

trunk

release

A D E F

G

H J L K

M I C N B

releaseブランチ作成

trunkをコピーしてreleaseブランチを作成する

SVNはリポジトリー内の通しリビジョンなのでreleaseブランチ作成でもリビジョン番号が付加される

trunk

release

A

B

リリース先向けカスタマイズ

リリース先に合わせた変更をreleaseブランチにコミットする

ファイルパス、URL、環境変数、etc...

この段階でリリースが可能になる

リリースブランチをエクスポートするだけ

trunk

release

A

B C

開発が進む

開発ブランチであるtrunkにコミットされる

releaseブランチは変更されない

trunk

release

A

B C

D E F

releaseブランチへのマージ

trunkの変更を、「対象モジュール単位」でreleaseブランチにマージする

Subversionのマージ機能を活用する

releaseブランチでは、trunkの複数コミットがまとめられてコミットされるイメージになる

trunk

release

A

B

D E F

G C

trunk、releaseブランチの成長

対象モジュールは開発チームが選定するため、trunkのコミット内容とreleaseブランチへの反映が前後することもある

trunk

release

A

B

D E F

G C

H J L K

M I N

releaseブランチの利点

開発を止める必要がない trunkとreleaseはそれぞれ別々に成長する

trunkが壊れてもreleaseには影響しない

リリース先に合わせたカスタマイズは初回のみで良い リリース環境が複数あるなら、それぞれに対するブランチを作成するだけ

リリース先のコードがすぐに参照可能 ただし、正しく同期を行うことが大切

リリース先でコード修正は原則としてしない

修正したら即座にreleaseブランチに反映し、trunkに逆マージする

まとめ

まとめ

リリース作業は日次で区切り、リリース対象機能の状態を管理して行う

リリース作業はreleaseブランチを用いた運用を行う

releaseブランチではリリース先に合わせたカスタマイズを行う

releaseブランチへはリリース対象モジュール単位にtrunkからマージする

リリースブランチへのマージはVCSの機能で行う