少し古いですが、「WEB+DB Press 2007 Vol39」の「構成管理実践入門」の記事を読みました。

「構成管理」という用語の定義は自明ではないですが、記事によれば、「バージョン管理」「ビルド」「リリース」の管理(自動化)と言えそうです。

バージョン管理はそれほど目新しい話題でも無いので、ビルドとリリース周りの管理に話を絞ります。

AirOneは、(主に)CとC++で本体が書かれていて、サーバ系は主にJavaとPerlです。C/C++のビルドは、MS-WindowsとUnix系で完全に別管理になっています。MS-WindowsはMSVCのビルドシステムに依存しています。コマンドラインでも実行できるので、自動ビルドも可能です。Unix系は(お馴染みの)autoconf/automakeベースです。Java系のビルドはantベースです。そして、細々した部分のつなぎあわせは、スクリプトとMakefileで行っています。

「細々した部分のつなぎあわせ」と書きましたが、ビルドの後、リリースまでには細々した部分をなんとかする必要性が確かにあります。この管理こそがまさに構成管理なのだと思います。経験上、ここへのアプローチに3つの流派がありそうです。

• U系 :小さなスクリプトを書きまくる
• W系 :手作業で頑張る。手順書を書いてプリントアウトする...
• J系 :フレームワークで隠蔽する

ちなみにW系が問題外なのは言うまでもありません。印刷された手順書を持ってきた瞬間に、破り捨てます。

アリエルには伝統的にU系の人が多いので、小さなスクリプトが氾濫する傾向にあります。言語も統一されず、Perl、shell、Python、(DOSの)バッチ、と雑多です。スクリプトファイルの数が増えると、スクリプトを順に呼び出すだけのバッチ処理用スクリプトが追加されて、更に数が増えたりもします。しかし、この辺の管理はどうにかできます。binとlibexecのようなディレクトリ分割で、直接呼び出すスクリプトと(それらが)内部的に呼び出すスクリプトを分けるのはひとつの伝統的なテクニックです。

ただU系流儀に問題が無いわけではありません。一番、問題に感じるのは環境依存の処理です。環境依存の処理をするには、実行時チェック(unameなど)や環境変数で動作を切り替えるのが常套手段です。手軽なので、環境変数での動作切り替えは(個人的には)多用します。残念ながら、これは手抜きであって、誉められた手法ではありません。経験上、環境変数は事故のもとです。

そして、J系アプローチです。冒頭の記事はMaven2とContinuumを紹介しています。

Maven2の第一印象は、「思想は悪くないけど、なぜantの補助ツールにしないのか?」です。(antの設定ファイル)build.xmlの生成元ファイルとしてbuild.xml.inを書いて、Maven2がbuild.xmlやディレクトリ構成を自動生成するアプローチで、目的の大部分は果たせる気がします。ぼくはantがそんなに嫌いではないのですが、単に使い込んでいないので悪いところが見えていないだけかもしれません。

社内のJavaプロジェクトの構成管理は微妙に問題をはらんでいる気がしています。たぶん、U系アプローチで突っ走る人とそうでない人が混在しているためだと思います。現実を見れば、J系アプローチに分がありそうです。

mavenとantで検索すると、こんな記事を見つけました(今年の5月の記事です)。

• http://japan.zdnet.com/oss/story/0,3800075264,20349166,00.htm
• http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/263DAEC1-9BB5-4283-8E51-5E169DBFAB04.html

いくらなんでもこれは違うだろう、と思います。