プログラマの思索

デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。
ソース管理について振り返ってみる。

【1】ソース管理の歴史

ソフトウェア開発では、ソース管理が必須だ。
ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。

昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。
今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。

僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。
CVSよりも直感的でGUIが使いやすい。

VSSを使い始めてから、下記の作業がルーチンになった。

朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートする。
↓
自分の担当のソースは、VSSからチェックアウトして、他人が修正できないように排他ロックする。
↓
夜、退社間際に、VisualAgeForJavaのワークスペースからエクスポートして、VSSへチェックインする。

これによって、新規開発でも、結合テスト以降のバグ修正でも、VSSのソースを最新版として管理できるようになった。

しかし、VSSの弱点は一つは、チェックアウトされたソースは担当者以外は誰も修正できないこと。
CVSと違って、VSSのチェックアウトは排他ロックであるため、一つのソースを二人が平行作業することはできない。
だから、共通ライブラリを同時に修正する必要がある時等は、プロジェクトリーダーが慎重にアサインする必要があった。

VSSの弱点のもう一つは、ブランチを切った後のマージ作業が面倒なこと。
Ver1.0を本番リリース後、Ver1.0をバグ修正するチームと、Ver2.0に向けて新規開発するチームに普通分かれる。
その時、Ver2.0へVer1.0のバグ修正をマージする運用ノウハウがなかったので、マージ作業中は、Ver2.0のソースを凍結したりしていた。
理由は、一気にマージしようとするので、マージするソース量が膨大だったから。

だが、その期間は、Ver2.0の開発が遅れてしまう。
しかも、マージ後のソースは、新規開発中の機能と衝突したりする。
だから、開発者も単なるマージ作業のメンテナンスで疲労したものだ。

最近は、Subversionを使い始めた。
すると、SVNでは、

/trunk
/branches
/tags

の3つを意識的に使い分けて、下記のようにソースを管理するのが普通。

最新ソースは常にtrunkにチェックイン。
↓
リリース直前にバージョンを付けて、tagへ入れる。
↓
リリース後は、ブランチを切って、保守モードにする。
ブランチにコミットしたソースは後からtrunkへマージする。

この方法で飛躍的にアジャイルに開発できるようになった。

しかし、最近のWebシステムは、極端な時は、1週間に1度はリリースする。
だから、そのたびに、ブランチを切る羽目になり、しかもマージ作業が発生する。

また、ブランチを切るタイミングがすごく難しい。
ブランチを延命させると、マージ作業が大変になる。

今でも、頻繁なリリースとソース管理の連携に非常に苦労している。

【2】ブランチを切るタイミング

そこで「パターンによるソフトウェア構成管理」を読み直した。

「パターンによるソフトウェア構成管理」では、下記のパターンを述べている。

2-1.trunkを開発のメインラインとする。

2-1-1.最新ソースの開発はメインライン。
　メインラインは常にビルドが通るようにする。
　
2-1-2.ブランチはメインラインから行う。
　つまり、ブランチからブランチを切ることはしない。
　
2-1-3.ブランチしたら早めにメインラインにマージするようにする。
　マージ作業のコストを減らすため。

2-2.ブランチを切るタイミングは複数ある。

2-2-1.リリースブランチ
　大きいバージョンアップのリリース直前に、メインライン上でtag付け後、ブランチを切る。
　普通はこの場合が多いだろう。

　メインライン(trunk)が新規開発で、ブランチが運用保守。
　利点は、リリース期間中に、保守と新規開発の2つの開発を平行できることだ。

　「パターンによるソフトウェア構成管理」では、運用保守のブランチをリリースライン、又はリリースブランチを呼んでいる。
　理由は、既に安定しているリリースブランチにパッケージングや些細なUI修正などを施して、ブランチを延命する場合もあるからだ。

　つまり、もう一つの場合は、リリース用モジュールを早く作りたいために、リリースする前から早めにブランチを切る。
　そのような場合は、ブランチ上で、微小なUI修正など直近のリリース作業に専念する。
　新規機能の実装は、メインライン上で行うようにソースを分ける。
　
　メインラインへマージする作業はおそらく頻繁に発生する時もあるが、リリースブランチが安定すれば、マージする回数も減ってくるだろう。

　この手法の利点は、リリース作業に専念するリリースブランチがあるので、メインライン上で新規開発を凍結しなくてもいいことだ。

　この手法は、複数の顧客ごとにカスタマイズした機能を付けて順にリリースしなければならない時にも使えるだろう。

2-2-2.タスクブランチ
　メインラインへ大きな影響を及ぼす修正が必要な場合、ブランチを切って、ブランチ上で実験する。
　「パターンによるソフトウェア構成管理」ではタスクブランチと呼んでいる。

　この手法を使う場合は、共通ライブラリのバージョンアップや新規追加、ビッグ・リファクタリングをする時のように、メインラインのソースを大幅変更する場合に使う。
　
　この手法を使う回数は少ないだろうが、一人の開発者が大量のソースを修正しなければならない状況も、時にはある。
　その時、メインライン(trunk)に不完全なソースをコミットして欲しくない。
　
　だから、故意にブランチを切って、そのブランチ上で完成するまで作業してもらう。
　タスクブランチへメインライン上のバグ修正ソースをマージする時も多々あるだろう。

【3】RedmineのプロジェクトとSVNブランチを連携させる利点

　上記のようにtrunkとブランチを意識して使い分けた場合、「どんなバグ修正や仕様変更が反映されているのか？」を管理することが重要になってくる。
　ここで、Redmineの複数プロジェクト管理が有効に使える。
　
　つまり、Redmineの親プロジェクトには、SVNリポジトリのtrunkを紐づけておく。
　そして、Redmineの子プロジェクトごとに、SVNリポジトリの各ブランチを紐付けるのだ。
　
　これによって、新規開発のチケットと運用保守のチケットを別々に管理するのが簡単になる。
　チケットとSVNリビジョンが紐づいているので、どんなバグ修正や仕様変更がソースに反映されたのか、がチケットからすぐに分かる。

　特に、結合テスト以降リリース直前までの期間は、バグ修正と仕様変更が入り乱れる。
　だからこそ、デグレが起きないように、常にtrunkが最新ソースで最も安定するように保守していくのは最重要なのだ。

【4】Subversionのブランチ管理はアジャイル開発の配管作業

　VSSが駄目なのは、いつもメインライン上でしかソースを修正できないこと。
　でも、SVNでブランチを切りすぎると、マージ作業が大変になる。
　
　ここで、日次ビルドできる環境があれば、マージ作業後の検証も楽になる。
　素早く検証できるビルド環境とソース管理は密接に関連する。

　また、Linuxでは、GITのようなツールで、更にマージ作業が簡単になるようにブランチ管理しているようだ。
　GITは詳しく分からないけれども、その発想は頷けるものがある。

　ブランチを有効活用すれば、頻繁なリリースに耐えうる開発プロセスを作ることができる。