ドキュメントも構成管理すべきだ

SVNで構成管理する時の良い記事が公開されたのでメモ。

【元ネタ】
Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所

SVNの使い方の記事はネット上にいくらでもある。
しかし、上記の記事で重要と思われる内容は、構成管理や変更管理の考え方を初心者向けに分かりやすく説明している点と、ドキュメント管理に構成管理の考え方を入れるべきだという主張だ。

CMMIの観点では、ソフトウェア構成管理は「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されている。
この考え方に基づくと、バージョンとは実はプロセスのベースラインを意味する。
つまり、リリース時にバージョン(又はタグ)を付けるタイミングは、開発者から顧客へ、あるいは営業チームから顧客へ、などのように、他者へ成果物を手渡すタイミングと同一なのだ。

構成管理が変更管理と密接に関係する理由は、上記のような変更プロセスを制御するインフラが構成管理だからだ。

そして、後者のように、ソースだけでなく設計書などのドキュメントも構成管理の配置下に置くべきだ。
理由は、ソースと同様に、ドキュメントを提出するタイミングでバージョン付けする状況が発生するからだ。

SVNはWindowsクライアントTortoiseSVNが非常に優れていて、ExcelやWordの差分表示もできる。
従って、変更理由の検索やマージ作業がやりやすくなる。

また、ロックと言う概念の説明も分かりやすい。
VisualSourceSafe6.0の頃は、VSSの管理下のファイルは全てロックされていたため、安全なように思われていたがむしろ作業に支障をきたす時が多かったように思う。
CVSやSVNのようにロックをかけないチェックアウトの方がやりやすいと思う。

また、trunk/branch/tagの説明も分かりやすい。
SVNが構成管理ツールの中で最も画期的だったのは、ブランチと言う概念を明示的に導入したことだと思う。

実は、昨今のシステム開発は殆どが、SWプロダクトラインのように、trunkとリリースブランチの2本以上による並行開発のはずだ。

例えば、組み込み製品やパッケージ製品の開発に従事する開発者ならば、製品ファミリーの開発を通じて並行開発には馴染みがあるだろうし、その苦労を嫌ほど分かっているだろう。
また、オープンソースで開発しているシステムの殆どは、障害修正だけの保守ブランチと最新機能をどんどん追加するtrunkの2本で開発しているだろう。
そして、昨今の業務系Webシステムでも、本番環境で動くリリースブランチと裏で機能拡張しているtrunkの2本で並行開発しているはずだ。

並行開発の難しさは、コードラインが2本あるためにタスク管理がより増大すること、そして、マージ作業が大変になる2点にあると思う。

そしてこの2点の問題を解決する糸口は、構成管理にあると直感している。
つまり、タスク管理はチケット駆動開発のように、BTSチケットに構成管理情報を付与してタスクを管理しやすくする。
マージ作業は、分散バージョン管理のようにマージ作業をツールで自動化する環境をサポートする。

構成管理はVSSやCVSの頃に比べるとはるかに高機能になり、それにつれて制御できるプロセスの範囲も広がってきた。
特に分散バージョン管理には、構成管理に新しい発想を取り入れているように思う。

構成管理という最も基本的な考え方をIT技術者だけでなく、PCに触る一般人も慣れた方がいいだろうと思う。