構成管理とは何なのか

技術

最近職場では構成管理というキーワードが（どちらかというと悪い意味で）ホットなのですが、考えてみるとこれは人によってイメージが違う抽象的な概念ですね。ソフトウェア単体の話じゃなくてインフラ環境まで含めた総合的なソフトウェア、ハードウェア環境の変更管理をイメージする人もいるみたい。なので議論しようとすると発散しやすいのかも。抽象的な話をしても伝わりづらいのである程度具体的な話をしないと噛み合ないのかもね。

ちなみに構成管理でぐぐると

チケット駆動開発をRedmineで運用し始めて、SW構成管理(Software Configuration Management：SCM)を強く意識するようになった。
しかし、SW構成管理をきちんと定義している書籍もHPも、日本には殆ど存在しない事実を知って、愕然とした。

CMMIでも構成管理プロセスを定義しているけれども、僕の中ではフィットしない。
抽象的すぎて、現場で運用できるレベルではない。
ITILの構成管理が、僕の中では最もフィットするが、何が核心なのか分かり辛い。

SW構成管理とはそもそも何なのか？: プログラマの思索

たしかにそうですね。

Subversionを用いたソースコードのバージョン管理なんかがイメージしやすいとは思うのですが、構成管理のすべてではないし、そもそも日付管理で十分な人にはこれも伝わりづらい。僕個人としてもTrac,Subversionの連携を経て構成管理を意識するようになった気がします。

構成管理をあえてひとことで言うなら

ソフトウェア構成管理（Software ConfigurationManagement、SCMとも呼ばれます）とは簡単にいうと、「ソフトウェアに対するすべての変更や修正を記録し、成果物をいつでも（場合によっては過去にさかのぼってでも）作成できるようにすること」です。

\¬ŠÇ—@ŽÀ‘H“ü–å@‘æ1Í \¬ŠÇ—“ü–å@–{“ÁW‚ňµ‚¤“à—e

ということになるでしょう。

構成管理をあえて分類するなら下記のような感じかな。版管理、変更管理、環境管理は基本的に言語非依存の話になると思います。

1.版管理

版管理は要はバージョン管理で、構成管理対象要素（例：ソースコード）を誰がどのように変更したかを管理するものです。ツールとしてはSubversionlが挙げられるでしょう。ちなみにどう変更したかはわかっても何故変更したかはコミットコメント見るとか、後述の変更管理ツールと連携する必要があるでしょう。

管理対象がテキストなら差分をみたりマージしたりすることができます。バイナリも格納できますが、差分が見れないのでコミットコメントとコミット日付をたよりに変更を管理することになります。

何を構成管理対象とするかはいろいろ議論があると思います。Javaのclassファイルのように何かから生成できるものは管理せず、生成元だけ管理するでしょう。ただし自動生成ソースなんかは量が多いことやチェックアウト時にコンパイルエラーがおきないようにあらかじめコミットすることが多いでしょう。コンパイルエラーをさけるためライブラリもコミットすることが多いんじゃないかな。ビルドに必要なものはすべてコミットするというのがマーチンファウラー流ですね。たしかw

OSのパッチやミドルウェアも管理しようと思えばできますが、容量の関係でやらないことが多いでしょう。あえてやるなら何にどのパッチを当てたかの一覧をテキストでつくって構成管理対象にするとかかな。ただ最近は仮想化の技術が進んでいるので、OSも含めてまるごと管理することは可能です。VMWare Fusionのスナップショット機能なんかはまさにそれですね。

DBもDDLやマスターデータを構成管理対象とすれば版管理できます。RailsのActiveRecord,S2JDBC-Gen,DBFlute, Jiemamyあたりはその系統かな。

ブランチを用いた並行開発の話もここに含まれるでしょう。

2.変更管理

変更管理はバグ管理も含めたものです。機能追加のようにどういう変更をするのかを記録して管理します。Trac,RedmineならチケットIDで識別して管理するでしょう。コミットコメントにチケットIDを含めることにより変更とソースのdiffをリンクさせることができます。これにより誰が、なぜ、どのように変更したのかを追跡することができます。なぜ重要。

3.ワークスペース管理

ワークスペース管理は各開発者のローカル環境の話です。Eclipseのワークスペースをイメージすればいいでしょう。例えばMavenを使っている場合はライブラリはコミットしないで、mvn eclipse:eclipse して.projectや.classpathを生成してEclipseのプロジェクトとしてインポートして開発するでしょう。ソースをチェックアウトしてどれだけ手間ひまかけずに開発に着手できるかというのがポイントです。パスやIPアドレスのような環境依存の情報の管理の話もからみます。これは後述のビルド管理で書きます。

4.ビルド管理

ソースコードをコンパイルしてパッケージングする話です。ローカルと結合環境では設定値を変えなければいけないときはビルド時に切り替えるでしょう。この辺JavaならAntやMavenで自動化するでしょう。Jenkinsを使えばビルド番号やファイル指紋を付与してビルド成果物を識別することが可能です。

5.リリース管理
ビルド成果物をサーバにデプロイします。サービス停止、古いファイルの削除、新しいファイルのコピー、サービス起動という流れになるでしょう。ビルド成果物自体もどっかのファイルサーバに保管するのが一般的かも。リリース物にどんな変更が含まれているかというリリースノートはTracならマイルストーンで作るとかかな。

6.環境管理
インフラ系の話ですね。httpd.confのようなミドルウェアの設定ファイルも構成管理対象になるでしょう。やったことないけどw　リリース物をどのサーバにリリースしたかの管理もしたほうがいいのかな。



以上、モヤモヤしていた脳内クラウドの一部をはきだしてみますた。