人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

設定ファイルなどのバージョン管理について、デフォルト値が設定された基本となるファイルがある一方で、導入先ごとの、例えばホスト名などが少しずつ異なる版も多数(数十とか)管理したいという場合、どのようにするのがよいでしょうか。
新しい設定項目が追加された場合は全部にもれなく反映される必要があります。

このような場合に個別版をブランチとして管理するという考えは適切でしょうか?
実際の事例とか推奨されるパターンのようなものを教えてくれるとありがたいです。

●質問者: mach2012
●カテゴリ:ウェブ制作
○ 状態 :終了
└ 回答数 : 1/1件

▽最新の回答へ

1 ● a-kuma3
ベストアンサー

考え方としてはブランチで良いと思いますが、使っている VCS だったり、その管理の単位によっていろいろとありそうな感じがします。

例えば、Subversion で、その「設定ファイルなど」の管理がソースなんかと一緒くたになってるとしたら、考えただけでちょっとげっそりします。

Git であれば、マージは楽ですが、導入先が多ければやはり手間は大きいですし、使っているスタイルにもよりますけど、どこからブランチを切るの、というポリシー的な解決は必要です。

ブランチを切るとしても、設定ファイルだけのプロジェクトにしておいた方が良さげな気がします。
# CVS だったら、気にしなくて良いけど

新しい設定項目が追加された場合は全部にもれなく反映される必要があります。

このような要求があるのであれば、VCS の外で解決すべきだと思います。

ぼくなら、設定ファイルなら、ふたつのファイルを重ね読みするような構造にします。

ひとつは、システムのよくある設定値(デフォルト値)を持った設定ファイル。
全ての設定項目を持ちます。

もうひとつは、導入先毎で変更した設定値を持った設定ファイル(差分)。
同じ項目名は、先のファイルに定義がありますが、こちらに設定した方が優先するように読み込みます。

バージョンアップなどで設定項目が増えた場合には、それを扱うプログラムのソースと、デフォルトを持った設定ファイルだけが更新されます。
その項目を変更する必要がある導入先だけ、差分のファイルに新しい項目の定義を追加してコミット。

Git なら、ソースと一緒くたで管理でも、問題ないと思います。
Subversion だったら、やっぱり差分のファイルは別プロジェクトでの管理で。



質問には「設定ファイルなど」ってありますね。
環境構築用のスクリプトとかに、IPアドレスとかホスト名が直に書き込まれているのでしょうか。

こいつらは、変更されるような値をスクリプトの外に出します。
そして、そのファイルは、先の設定ファイルと同じ扱いにします。

関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ