2.2. 管理の対象

構成管理の主な対象はファイルとなりますが、どのようなファイルを構成管理すべきでしょうか。

プロジェクトによっては、テストコードはコミットしない、データファイル・設定ファイルはコミットしない、ドキュメントやDBのCREATE文はファイルサーバに 置いて管理する、などの不思議なルールがまかり通っています。果たして、これらのファイルを構成管理下に置かないメリットはあるのでしょうか。 我々は、そのデメリットの方が大きいと考えています。

その他にも色々なデメリットがあると思います。対して、これらのファイルを構成管理したがらない人が主張するのは「関係ないファイルを置きたくない」 「置いても管理できない」等でしょう。ドキュメントは果たして「関係ないファイル」なのか。構成管理システム下に置かない事で「管理できるようになる」のか。 今一度考えて頂きたいところです。

構成管理の理想的な運用目的は、「コンパイルできる状態のソースコードを維持」することではなく、 「正常に動作する状態のシステムを維持管理する」ことです。この視点で考えると、例えばDBの初期化スクリプト(SQL文など)を 構成管理しなかった場合、ソースコードについては過去の状態が呼び出せたとしても、それに依存するDBの状況が再現できません。当時のDBは、どのような テーブルがあるべきだったのか。恐らくその点は、誰も管理していないと思います。つまり、昔の状態のアプリケーションを、もはや正常に動かす事ができないのです。

以上の理由により、我々は、ソースコードだけではなく、プログラムの動作に必要なファイルだけではなく、そのプロジェクトにまつわる 全てのファイルを構成管理すべきだと主張します。