バージョン管理と個人設定ファイル

このプロジェクトでは、ユーザー固有の構成ファイルを使用します。このファイルは、ユーザーごとに異なるため、現在バージョン管理されていません。問題は、開発者が構成を必要とする新しいモジュールを追加するか、既存のモジュールの名前を変更すると、プライベート構成ファイルが更新されないため、他の開発者にエラーが発生することです。

この問題を解決するために、2つの構成ファイルで作業することを考えました。バージョン管理になり、新しいモジュールを追加する各開発者によって定期的に更新されるデフォルト/グローバル構成ファイルと、除外されるプライベート構成ファイルバージョン管理され、ユーザー固有の変更のみが含まれます。

ただし、これは依然としてアドホックなソリューションのようです。

より良い解決策を提案できますか？

専門家は何をしますか？

すでに良い答えが得られていますが、それらのほとんどは問題の根本的な原因を見逃しています：ユーザー設定ファイルにはユーザー固有の情報だけでなく、バ​​ージョン管理下にある（おそらく冗長な）情報も含まれているようです、おそらくモジュール名のような異なるファイルで。

ここで2つの可能な解決策を考えることができます：

• その情報を厳密に分離するようにしてください。たとえば、ユーザー設定でモジュール名を使用しないでください。ID番号（GUIDなど）を使用してモジュールを参照し、それらのID番号がモジュールに割り当てられた後に変更されないようにします。もちろん、これにはおそらく、ユーザーの構成ファイルが現在持っている単純さの一部を失うという欠点があります。おそらく、プレーンテキストエディターを使用する代わりに、構成ファイルを編集するためのGUIツールを作成する必要があります。

• 構成ファイル形式にバージョン番号を付け、モジュール名などが変更されるたびに、新しいバージョン番号を割り当てます。次に、バージョン番号をチェックするアップグレードスクリプトを提供できます。構成ファイルが最新でない場合は、ファイル内で見つかったすべてのモジュール名を変更し、その後バージョン番号を増やします。これは自動化できるため、アップグレードのプロセスによって、チームメイトの日常業務が妨げられることはありません。

編集：投稿をもう一度読んだ後、新しいモジュールが追加されただけで名前が変更されていない限り、想定される解決策は妥当だと思います。上記で書いたものは、後でモジュール名または既存のモジュールの構成の構造を変更することができます。しかし、あなたがそれを必要としないなら、私は最も単純な解決策に固執するでしょう。

それは合理的な解決策です。

新しい構成要素の初期値を指定する方法が必要です。これらはどこかに保存する必要があり、グローバルな読み取り専用の構成ファイルは当然の選択です。

次に、各ユーザーが個人の構成を変更すると、これらの変更をローカルコピーに書き込みます。

コードは、最初にグローバル構成とユーザー固有の構成を読み取って、変更された値を上書きする必要があります。これは、ローカルのものを読み取り、設定されていないためグローバル設定ファイルから読み取る必要があるものを解決しようとするよりもはるかに簡単です。

ストレージにXMLのようなものを使用する場合、設定を削除する場合の処理​​を心配する必要はありません。ファイルのユーザーコピーから要求されることはなく、保存時にファイルを再作成すると、変更後にアプリケーションが初めて使用されたときに削除されます。

おもしろい解決策があり、主にPHP開発者であるため、PHPで記述された自動化されたタスクを作成できるPhingを使用するため、通常のsvn updateを行う代わりに、svn updateを呼び出す「phing update」を行います。そして、設定を適切な変数、たとえば設定で置き換えます：

$db_user = "${test.db_user}";

そのため、構成ファイルはすべてその興味深い構文でバージョン管理され、その後、特定のインスタンス用のアドホックでバージョン管理されていない構成ファイルを生成し、それらの「変数」をバージョン管理されていないiniファイルで指定されたバージョン管理されていない設定に置き換えます。このようにして、ユーザー固有のファイルを変更し、他の作業コピー全体に変更を反映させることができます。

プログラムには、構成ファイルで値が見つからない場合のコードのデフォルト設定が必要です。このように新しいものが追加されても壊れることはなく、アップグレードパスがよりスムーズになり、ユーザーが構成ファイルを台無しにした場合のフォールバックもあります。

別のより複雑な例は、プログラムの起動時または他の重要なポイントで、初期化モジュールを使用して構成ファイルを開き、欠落しているデフォルトを追加しますが、これはかなり重いようです。

バージョン番号を個人用構成ファイル（構成ファイル形式のバージョン番号）に入れます。

個人用構成ファイルを処理するコードにバージョン番号を確認させ、バージョンが古い場合は更新手順を実行します。したがって、基本的に、既存の構成ファイルを壊すような変更を行う場合は、構成ファイル形式のバージョン番号を上げ、前のバージョンの構成ファイルを更新する手順（セクションの名前を変更するなど）と再保存する必要がありますそれら。

とにかくエンドユーザー向けにこのようなプロセスが必要になるので、開発者の生活を楽にするために使用することもできます。

通常、私がそれをどのように見てきたかは、デフォルト値を含む設定ファイルをリポジトリにチェックインすることです。これらは、例として、テストサーバーで必要な値です。次に、開発者がファイルをチェックアウトすると、すべての値が設定されます。新しいフィールドが追加されるか、フィールドが削除されると、これはマージで処理されます。開発者は、ターゲットサーバーに必要な値をチェックインし、自分の開発環境用のフィールドへの他の変更はチェックインしません。

マージが正しく行われるように注意しますが、私にとってはかなり安全なようです。

ここで行うのは、設定のブロックを作成することです。これは、Zendで次のように実行できます。

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

これは、テストが実稼働を継承し、key3で拡張することを意味します。その後、各開発者が行う必要があるのは、環境を設定することだけです（この場合はテストまたは実稼働）

これは、投稿に基づいた便利なソリューションです：ソース管理でパスワードを保持する

要約すると、戦略は「構成ファイルの暗号化されたバージョンをソース管理に保持し、ユーザーがそのデータを暗号化および復号化できる手段を提供する」ことです。

1. ダミーのcomfigファイルを作成し、.gitignoreします。
2. 構成ファイルを暗号化および復号化できるメイクファイルを作成します
3. メイクファイルと暗号化された構成ファイルをリポジトリに保存します
4. メイクファイルはパスワードを要求し、作成者にパスワードを問い合わせる方法を尋ねます。
5. プロジェクトをビルドするときに、メイクファイルが実行されていない場合は、console.error（ "Config file [conf / settings.json] missing！実行を忘れましたmake decrypt_confか？"）;
6. 設定ファイルが最新であることを確認するためのチェックについて説明します。

このような構成の問題を処理するConfigというツールを作成しました。1つのマスター構成ファイルを作成（またはインポート）します。次に、Localという環境を作成します。ローカル環境で、複数のインスタンスを作成します（ユーザーごとに1つのインスタンス）。新しい構成エントリの追加やモジュール名の変更など、ボード全体で共通の変更を行う必要がある場合は、変更を加えるだけで、ボード全体に適用されます。インスタンス/ユーザーを変更する場合は、その構成値を変数にしてから変数を変更します。この変更は、インスタンス/ユーザーにのみ適用されます。これらはすべてバージョン管理下にあります。プッシュまたはプルを使用して構成ファイルをデプロイします。pullオプションはgit pullと似ていますが、特定のインスタンス/ユーザー向けです。

構成は、ユーザー間の構成の比較、検索、タグ付け、検証、ワークフローなどの追加機能を提供します。これはSaaSなので、まだクラウドの準備が整っていない人向けではありませんが、オンプレミスプランがあります。