2系統のバージョン管理戦略

OpenPNEというオープンソースのSNSのブランチの説明があったので、メモ。
非常に参考になる。

OpenPNEレポジトリ構造

OpenPNEソースコードは主に4種類のブランチで成り立っています。

1.最新の開発版を反映するトランク
2.リリースの安定版を反映するリリースブランチ
3.将来本線に取り込まれることを予定した、プロジェクトブランチ
4.開発者がバグ修正時や研究時に利用するワークブランチ

最近のソフトウェア開発は、短い期間でリリースしなくてはならない。
特に、1次開発後に機能追加して拡張していく場合、最近はリリース間隔が非常に短くなっている時が多い。

基本的な戦略は、バグ修正と機能追加のバージョン管理を上手に使い分けること。

一つの解決策としては、リリースブランチでバグ修正しながら裏では、trunkで機能追加しながら品質を確保する2系統戦略があるだろう。
例えば、奇数バージョンが保守ブランチ、偶数バージョンが大幅機能追加のブランチのような戦略。

この戦略の利点は、バグ修正と機能追加のブランチが区別されているので、品質を確保しやすいこと。
バグ修正のブランチは、修正していくほど、品質は安定していく。
機能追加のブランチは、追加するほど不安定になるので、試行錯誤しながら手を加えていく。
だから、表のリリースブランチの裏で時間をかけて行う。

2つのバージョン管理とマージ作業、それらに伴うプロジェクト管理の手法は、Redmineのようにプロジェクト管理機能を持つBTSでないと、もはやプロジェクトを運営できなくなっているだろう。
つまり、2系統のバージョン管理に伴う作業をBTSチケットに紐付けて、きちんと状態をトレースすることが大事。

最近の2系統のバージョン管理戦略とプロジェクト管理機能を持つBTSはセットで運用すべきだと思う。