ソース管理に構成を格納しますが、開発者ごとにバージョンが異なります

Question

設定ファイルによって管理される開発者ツールチェーンがあります。各開発者は、独自のバージョンの設定ファイルを持つことができます。単一のGitリポジトリに開発者ごとにその構成の個別のバージョンを格納するための良い方法は何ですか？私が考えているのは、開発者の名前でそれを分離し、すべての設定ファイルをディレクトリに置くことだけです。その後、各開発者はenv varを使用して、自分の名前の正しいファイルをポイントします。

それはちょっとラメなようですが、これを行うための洗練された方法はありますか？

Flater · Accepted Answer

これは、私が取り組んできた過去のプロジェクトでよくある問題です。いくつかのアプローチがありますが、それらにはすべて欠点があります。

Git無視

デフォルトファイルをGitリポジトリに置くだけで、開発者はデフォルトファイルをチェックアウトできます。ただし、開発者は変更を無視をこのファイルに追加し、チェックインしないでください。

Pro：本当にシンプルで、一般的に好まれるオプションだと思います。
Con：開発者のエラーが発生しやすく、リポジトリの修正が必要になる可能性があります。

環境変数

私はまだこれを考慮していませんでしたが、あなたは興味深い可能性を提起しました。ただし、私はこのアプローチのファンではありません。

Pro：機能します。
Con：新しいマシンで開発を始めるのが難しくなります+環境変数の設定は面倒です。

環境変数を使用しない同様のこと（5を参照）を実現する方法は他にもあるので、環境変数を回避することをお勧めします。それらは望ましくない依存関係です。

Machine.config

Machine.configファイルは、マシン固有の設定を使用するために特別に作成されました。ただし、これを望ましくないアプローチにするいくつかの欠点があります。

Pro：動作します。
Con：アプリケーションの構成ファイルはmachine.configよりも優先されるため、望ましくない結果が生じます。サーバー（本番環境）でも、設定にmachine.configを使用する必要があります、またはdevとprodの間で設定を変更する必要があります。どちらも良い選択肢ではありません。

私が知る限り、machine.configをweb.configよりも優先させる方法はありません（例：!Important in CSS）。これを行う方法がある場合、このアプローチはより実行可能になります。ただし、すべてのプロジェクトで同じmachine.configに依存しているため、これがそのマシンで複数のプロジェクトに取り組んでいる開発者に競合を引き起こすかどうかはわかりません。

私の推奨するアプローチ：

2つのファイルを作成する傾向があります。 default.configおよびweb.config（またはapp.config）。他の名前を自由に使用してください。

default.configはgitリポジトリに登録されており、実際のデフォルトの構成ファイルが含まれています。
web.configはgitリポジトリに登録されていません。開発者は単にdefault.configファイルを（新しく作成された）web.configファイルとして保存し、必要に応じて調整できます。
Default.configファイルは、Gitリポジトリの「単なるファイル」です。
VSソリューションは、web.configファイルを使用するように設定されています。
開発者がコミットする変更の新しい構成キーを追加してしまう場合、開発者はこれらのキーをdefault.configに追加してGitにコミットすることが期待されています。

これには、私の意見では、それを価値のあるものにするいくつかの利点があります。私にとって、最も重要な利点は、誰かが設定キーを追加/削除する変更をコミットした場合、誰もが自動的に新しいキーをチェックアウトするため（更新を認識しているため）、追加/削除されたキーはローカルにすぐには影響しません設定ファイル。

Pro：先ほど言ったこと。
Con：開発者は2つの設定ファイル間で設定を手動で同期する必要があります。これまでの私の経験では、これは通常30秒のコピー/貼り付けジョブに相当するので、過度の手間ではありません。ただし、開発者が変更をコミットしてdefault.configを更新するのを忘れることは珍しくありません。そのため、プルを行った後に他の開発者が問題を引き起こす可能性があります。

（unested）カスタム構成構成

これは同僚が提案したもので、環境変数と同様に興味深いアイデアです。しかし、これはまだ使用していません。

アイデアは、プログラムで構成ファイルを作成することです。 web.configの参照をセカンダリ構成ファイルに追加する方法と同様に、この参照をプログラムで追加できます。コードを介してそれを行うことの利点は、2番目の構成ファイルの名前を動的に決定できることです（たとえば、ユーザー名に基づいて）。
さらに、たとえば、この追加の読み込み動作を無効にすることができます。構成スイッチを使用します。つまり、本番環境では基本構成ファイルのみを使用できるようにします。

これは、USERNAME.configファイルは、web.configファイルの特定の設定をオーバーライドします。これらのファイルはすべてチェックインでき、ある開発者が別の開発者の構成設定を使用できるようにすることもできます（たとえば、問題を再現する場合）。

注：開発者固有の設定ファイルの代わりに、ハードコードされた「localDevOverride.config」ファイルに対して同じことを行うことができますが、そのローカルファイルをチェックインすることはできません。私はそれらのファイルをチェックインしたいので、開発者が別のマシンで作業する必要がある場合（たとえば、古いマシンが停止した場合）は、設定が失われません。

Loren Pechtel · Answer