メインラインモデルとソフトウェアプロダクトラインの類似性

アジャイルプラクティス勉強会in関西に出て、メインラインモデルをソフトウェア構成管理の視点から興味深い指摘があった。

組み込み系では、メインラインでソース管理していても、多種類の似たような製品を作る派生開発が多い。
例えば、iPodのように、似たような機能だがどれも微妙に仕様が異なる家電製品など。

元々、組込系製品やパッケージ製品では、製品ファミリーを展開して、多品種少量生産で売り込むビジネスが多い。
だから、製品ファミリーのソフトウェア構成管理にソフトウェアプロダクトラインの概念を持ち込む手法は、10年以上前から実践されてきた。

有名なビジネスモデルは、MSのOffice製品やMSが展開する製品群がそれに当たる。

本来、メインラインモデルのように、リリースブランチ・メインライン・作業ブランチのようにソース管理を複数のラインで管理する時、コア資産とアプリケーション独自の資産を分ける。

この時、メインラインがコア資産に相当し、個々の製品ファミリーはリリースブランチに相当するだろう。
そして、個々の製品開発チームは作業ブランチで開発しているだろう。

しかし、メインライン上でコアとなるソースは管理して、派生開発のソースはブランチで管理するが、結局ブランチは独立したソース管理になってしまい、構成管理が破綻するケースが多い、と。

確かに、一度、ブランチを切ってリリースしていくと、ソースがどんどん膨大に増えてゆき、マージ作業が大変になり、誰も手を付けられなくなるのが現状だろう。

更に、ブランチとメインラインのソース管理が独立してしまうと一番困るのは、共通ライブラリに緊急のバグ修正が発生した時、全てのブランチで確認を取らないといけない時。

昨今は、ノートPCが熱暴走したとか、電池が爆発したとか、会社の存続に関わるバグ修正が時に発生する。
だから、そのようなケースが発生した時に、確認を取るのに時間がかかりコストもかかる、と。

これはまさにソフトウェアプロダクトラインの発想を実践しようとして、結局できなかったという話そのもの。

コア資産という再利用できるソースが、結局、各ブランチで独自展開して管理できなくなり、最終的には手に負えなくなる現状を示している。

パッケージ製品開発を誰もが夢見て実践して、なかなか成功しない理由は、メインラインでコア資産を制御することが難しいことにあるのだろう。

だから、Webシステム開発では、再利用なんか考えずに3年でシステムをリプレースしてしまえばいい、という極端な発想で開発するスタイルもある。

だが、3年で開発資金の元が取れるのかという心配もあるし、プログラマにとっても、保守しにくいシステムを運用していくのは嫌なものだ。

たとえWebシステム開発でも、1次開発が大成功すれば、必ずリピートオーダーがもらえて、運用保守しながら2次開発を進めることが普通。
顧客と深い信頼関係を築いた後ほど、1度作ったシステムは当初の予想以上に長く使われて、2次開発、3次開発とどんどんカスタマイズした機能を追加して、膨れ上がっていく。

その時に、運用保守のリリースブランチと、開発中のメインラインが発生する。

SVNでの現実的な運用方法は下記と考える。

1次開発中：
　トランクでソース管理。
↓
1次開発リリース直後：
　Ver1.0でタグ付け後、Ver1.0のリリースブランチを切る
↓
2次開発中：
　2次開発のソースはトランクで管理。
　Ver1.0のリリースブランチでバグ修正が入ったら、必ずトランクにマージする。
　当然、バグ修正後にVer1.1のタグも付ける。
↓
2次開発リリース直後：
　Ver2.0をトランクからタグ付けして、トランクからリリースブランチを作る。
　Ver1.0のリリースブランチは終了する。
　3次開発のソースはトランクで管理する。

つまり、生物進化の系統樹のように、リリース中と開発中のソースをきちんと分けて管理するのが現実的だろう。

パッケージ製品開発のように製品ファミリーを展開する場合は、もっと複雑な管理が必要になるのだろう。

バージョン管理はソフトウェア開発で必須なのに、意外にないがしろにされている気がする。