101

典型的な Web アプリがあり、ファイル構成があるとしましょう。プロジェクトに取り組んでいるすべての開発者は、開発ボックス用に 1 つのバージョンを持ち、開発、製品、ステージのバージョンがあります。ソース管理でこれをどのように処理しますか? このファイルをまったくチェックインしない、別の名前でチェックする、またはまったく凝ったことをしますか?

4

19 に答える 19

72

私が過去に行ったことは、ソース管理にチェックインされるデフォルトの構成ファイルを用意することです。次に、各開発者は、ソース管理から除外される独自のオーバーライド構成ファイルを持ちます。アプリは最初にデフォルトをロードし、次にオーバーライド ファイルが存在する場合はそれをロードし、デフォルト ファイルより優先してオーバーライドの設定を使用します。

一般に、オーバーライド ファイルは小さいほど良いですが、非常に非標準的な環境の開発者向けに常により多くの設定を含めることができます。

于 2008-08-08T14:50:00.287 に答える
24

構成はコードであり、バージョン化する必要があります。構成ファイルはユーザー名に基づいています。UNIX/Mac と Windows の両方で、ユーザーのログイン名にアクセスできます。これらがプロジェクトに固有のものである限り、問題ありません。環境でこれをオーバーライドすることもできますが、すべてをバージョン管理する必要があります。

これにより、他のユーザーの構成を調べることもでき、ビルドやプラットフォームの問題を診断するのに役立ちます。

于 2008-09-15T18:04:39.203 に答える
19

そのファイルをバージョン管理しないでください。テンプレートなどをバージョン化します。

于 2008-08-08T14:46:15.020 に答える
10

私のチームは、環境ごとに個別のバージョンの構成ファイルを保持しています (web.config.dev、web.config.test、web.config.prod)。デプロイ スクリプトは正しいバージョンをコピーし、名前を web.config に変更します。このようにして、各環境の構成ファイルを完全にバージョン管理し、簡単に差分などを実行できます。

于 2008-08-08T15:44:59.723 に答える
6

テンプレートアプローチで+1。

しかし、この質問にはGitというタグが付いているため、分散型の代替案が思い浮かびます。この場合、カスタマイズはプライベートテストブランチで保持されます。

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)

このスキームでは、メインラインに一般的な「テンプレート」構成ファイルが含まれており、機能するために最小限の調整が必要です。

これで、開発者/テスターは構成ファイルを心ゆくまで微調整し、これらの変更を1つのプライベートテストブランチでのみローカルにコミットできます（例：B'= B +カスタマイズ）。メインラインが進むたびに、メインラインを簡単にテストにマージします。その結果、D'（= D + Bのカスタマイズのマージバージョン）などのマージコミットが発生します。

このスキームは、「テンプレート」構成ファイルが更新されたときに非常に効果的です。両側からの変更がマージされ、互換性がない場合、競合（またはテストの失敗）が発生する可能性が非常に高くなります。

于 2008-08-31T11:01:56.727 に答える
6

現在、次のような拡張子が追加された「テンプレート」構成ファイルがあります。

web.config.rename

ただし、重要な変更が変更された場合、この方法で問題が発生することがあります。

于 2008-08-08T14:47:06.593 に答える
5

私は常にすべてのバージョンの構成ファイルをソース管理の web.config ファイルと同じフォルダーに保管してきました。

例えば

web.config
web.qa.config
web.staging.config
web.production.config

私はこの命名規則を好みます (web.config.production または production.web.config とは対照的に)。

  • ファイル名でソートすると、ファイルがまとめられます
  • ファイル拡張子で並べ替えると、ファイルがまとめられます
  • ファイルが誤って本番環境にプッシュされた場合、IIS によって *.config ファイルの提供が妨げられるため、http 経由でコンテンツを表示することはできません。

デフォルトの構成ファイルは、自分のマシンでローカルにアプリケーションを実行できるように構成する必要があります。

最も重要なことは、これらのファイルは、フォーマットを含め、あらゆる面でほぼ 100% 同一でなければならないということです。インデントに、あるバージョンではタブを使用し、別のバージョンではスペースを使用しないでください。ファイルに対して差分ツールを実行して、それらの違いを正確に確認できるはずです。ファイルの差分には WinMerge を使用することを好みます。

ビルド プロセスでバイナリを作成するときに、その環境に適した構成ファイルで web.config を上書きするタスクが必要です。ファイルが圧縮されている場合は、関係のないファイルをそのビルドから削除する必要があります。

于 2011-05-06T00:51:51.997 に答える
5

私たちが使用する解決策は、構成ファイル (web.config/app.config) を 1 つだけにすることですが、すべての環境の設定を含む特別なセクションをファイルに追加します。

LOCAL、DEV、QA、PRODUCTIONセクションがあり、それぞれに構成ファイル内のその環境に関連する構成キーが含まれています。

これをすべて機能させるのは、xxx.Environmentという名前のアセンブリです。これは、すべてのアプリケーション (winforms と webforms) で参照され、動作している環境をアプリケーションに伝えます。

xxx.Environment アセンブリは、特定のマシンのmachine.configから 1 行の情報を読み取り、それが DEV、QA などにあることを示します。このエントリは、すべてのワークステーションとサーバーに存在します。

お役に立てれば。

于 2008-09-16T18:47:00.780 に答える
4

以前は web.dev.config、web.prod.config などのテンプレートを使用していましたが、現在は「オーバーライド ファイル」手法を使用しています。web.config ファイルには設定の大部分が含まれていますが、外部ファイルには db 接続などの環境固有の値が含まれています。ポール・ウィルソンのブログの良い説明.

これにより、新しい値/属性を追加するときに問題を引き起こす可能性のある構成ファイル間の重複の量が減ると思います。

于 2008-09-08T16:11:26.820 に答える
3

@グラントは正しいです。

私は 100 人近くの他の開発者がいるチームに所属していますが、構成ファイルはソース管理にチェックインされていません。各チェックアウトでプルされるリポジトリ内のファイルのバージョンがありますが、それらは変更されません。

それは私たちにとってかなりうまくいっています。

于 2008-08-08T14:49:52.453 に答える
2

長い間、私は bcwood とまったく同じことをしてきました。ソース管理下に web.dev.config、web.test.config、web.prod.config などのコピーを保持し、さまざまな環境にデプロイするときに、ビルド/デプロイ システムがそれらの名前を自動的に変更します。ファイル間である程度の冗長性が得られますが (特にそこにあるすべての asp.net の場合)、通常は非常にうまく機能します。また、チームの全員が、変更を加えたときにすべてのファイルを更新することを忘れないようにする必要があります。

ちなみに、ファイルの関連付けが崩れないように、拡張子は「.config」を最後につけておくのが好きです。

構成ファイルのローカル開発者バージョンに関しては、独自のバージョンを用意する必要がないように、可能な限り同じローカル設定を使用するよう人々に勧めるよう常に最善を尽くしています。すべての人にとって常にうまくいくとは限りません。その場合、人々は通常、必要に応じてローカルで置き換えて、そこから移動します。痛すぎるとかそういうことじゃない。

于 2008-08-17T03:10:24.983 に答える
2

チェックインされたプレーン バニラ バージョンの app/web.config は、すべての開発者のマシンで動作するのに十分な汎用性があり、新しい設定変更などで最新の状態に保たれている必要があります。dev に特定の設定セットが必要な場合/test/production 設定、GateKiller が述べたように、ファイル拡張子を変更しないように、通常は「web.prod.config」を使用しますが、何らかの命名規則を使用して、これらの設定で個別のファイルをチェックインします。

于 2008-08-08T14:51:35.400 に答える
2

バージョン管理にチェックインされたテンプレート構成ファイルを使用し、自動ビルドのステップを使用して、テンプレート ファイル内の特定のエントリを環境固有の設定に置き換えます。環境固有の設定は、バージョン管理下にある別の XML ファイルに保存されます。

自動ビルドで MSBuild を使用しているため、MSBuild コミュニティ タスクの XmlUpdate タスクを使用して値を更新します。

于 2008-08-08T15:41:29.137 に答える
1

私たちのプロジェクトでは、プレフィックス付きのファイルに構成が保存されており、ビルドシステムは現在のシステムのホスト名に基づいて適切な構成を取り込みます。これは、比較的小さなチームの私たちにとってはうまく機能し、新しい構成項目を追加する場合に、構成の変更を他の人のファイルに適用することができます。明らかに、これは無制限の数の開発者がいるオープンソース プロジェクトには対応できません。

于 2008-09-05T22:43:30.773 に答える
1

私はそれをバージョン管理しますが、他のサーバーには決してプッシュしません。運用サーバーに変更が必要な場合は、構成ファイルに直接変更を加えます。

きれいではないかもしれませんが、うまく機能します。

于 2008-08-08T14:50:48.617 に答える
1

ここには 2 つの問題があります。

  • まず、ソフトウェアに同梱されている構成ファイルを制御する必要があります。

    デボルブメント環境で同じファイルを使用している場合、開発者が不要な変更をマスター構成ファイルにチェックインするのは簡単です。

    一方、インストーラーに含まれる別の構成ファイルがある場合、新しい設定を追加するのを忘れたり、その中のコメントが devolvement のコメントと同期しなくなったりするのは非常に簡単です。構成ファイル。

  • 次に、他の開発者が新しい構成設定を追加するときに、開発者が構成ファイルのコピーを最新の状態に保つ必要があるという問題があります。ただし、データベース接続文字列などの一部の設定は、開発者ごとに異なります。

  • 質問/回答がカバーしていない3番目の問題があります。 ソフトウェアの新しいバージョンをインストールするときに、顧客が構成ファイルに加えた変更をどのようにマージしますか?

すべてのケースでうまく機能する優れた解決策はまだ見ていませんが、問題を大幅に軽減する部分的な解決策 (必要に応じてさまざまな組み合わせで組み合わせることができる) を見てきました。

  • まず、メイン構成ファイルにある構成項目の数を減らします。

    顧客がマッピングを変更できるようにする必要がない場合は、Fluent NHibernate (またはその他の方法) を使用して構成をコードに移動します。

    依存性注入のセットアップについても同様です。

  • 可能な場合は構成ファイルを分割します。たとえば、別のファイルを使用して、Log4Net がログに記録する内容を構成します。

  • 多くの構成ファイル間で項目を繰り返さないでください。たとえば、4 つの Web アプリケーションがすべて同じマシンにインストールされている場合、各アプリケーションの web.config ファイルが指す全体的な構成ファイルがあります。

    (既定では相対パスを使用するため、web.config ファイルを変更する必要はほとんどありません)

  • 開発構成ファイルを処理して、出荷構成ファイルを取得します。

    これは、Xml コメントにデフォルト値を設定し、ビルドの完了時に構成ファイルに設定することで実行できます。または、インストーラーの作成プロセスの一部として削除されるセクションがあります。

  • データベース接続文字列を 1 つだけではなく、開発者ごとに 1 つ用意します。

    たとえば、最初に実行時に構成ファイルで「database_ianr」(ianr はユーザー名またはマシン名) を探し、見つからない場合は「database」を探します。

    第 2 レベルの "eg -oracle または -sqlserver" を使用して、開発者が両方のデータベース システムにすばやくアクセスできるようにします。

    もちろん、これは他の構成値に対しても実行できます。

    その後、構成ファイルを出荷する前に、「_userName」で終わるすべての値を取り除くことができます。

ただし、最終的には、上記またはその他の方法で構成ファイルを責任を持って管理する「構成ファイルの所有者」はあなたです。また、各出荷前に顧客対応構成ファイルの差分を作成する必要があります。

これほど問題がなければ、思いやりのある人の必要性を取り除くことはできません。

于 2009-10-20T09:03:42.027 に答える
1

構成ファイル内のデータの機密性、使用しているプログラミング言語、およびその他の多くの要因に依存する可能性があるため、すべてのケースで機能する単一のソリューションはないと思います。しかし、すべての環境の構成ファイルをソース管理下に置くことが重要だと思います。そうすれば、いつ、誰によって変更されたかを常に知ることができます。さらに重要なのは、問題が発生した場合に回復できることです。そして彼らはそうするでしょう。

だからここに私がそれをする方法があります。これは通常 NodeJS プロジェクト向けですが、他のフレームワークや言語でも機能すると思います。

私がしていることconfigsは、プロジェクトのルートにディレクトリを作成し、そのディレクトリの下に、すべての環境用の複数のファイル (場合によっては開発者の環境ごとに個別のファイル) を保持し、すべてソース管理で追跡します。また、コードが使用する実際のファイルはconfig、プロジェクトのルートに名前が付けられています。これは追跡されない唯一のファイルです。だからこんな感じ

root
|
|- config (not tracked)
|
|- configs/ (all tracked)
    |- development
    |- staging
    |- live
    |- James

誰かがプロジェクトをチェックアウトすると、追跡されていないファイルで使用したい構成ファイルをconfigコピーし、必要に応じて自由に編集できますが、必要に応じて他の環境ファイルにコミットする前にこれらの変更をコピーする責任もあります。

また、サーバーでは、追跡されていないファイルは、その環境に対応する追跡されたファイルのコピー (または参照) である可能性があります。JS では、そのファイルを要求するために 1 行を使用するだけです。

このフローは最初は少し複雑かもしれませんが、大きな利点があります。

  1. バックアップがなければ、サーバー上で構成ファイルが削除または変更されることを心配する必要はありません
  2. 開発者のマシンにカスタム構成があり、マシンが何らかの理由で動作を停止した場合も同様です。
  3. 展開の前に、たとえば と の構成ファイルを比較して、不足しているものや壊れているものがないかどうかを確認できdevelopmentます。staging
于 2016-02-04T16:53:12.177 に答える
0

プロダクション構成ファイルをチェックインしたままにします。ステージングまたは開発のために安全なソースからファイルを引き出すときに、ファイルを変更するのは開発者の責任です。これは過去に私たちを燃やしたので、私はそれをお勧めしません.

于 2008-08-17T04:10:42.820 に答える
0

私は同じ問題に直面し、その解決策を見つけました。まず、すべてのファイルを中央リポジトリ (開発者のものも) に追加しました。

したがって、開発者がリポジトリからファイルを取得すると、開発者の構成もそこにあります。このファイルに変更を加えた場合、Git はこれらの変更を認識しません。そうすれば、変更をリポジトリにプッシュ/コミットすることはできませんが、ローカルにとどまります。

git コマンドを使用してこれを解決しました: update-index --assume-unchanged. Git が変更を無視する必要があるファイルを含むプロジェクトのプレビルドで実行されるバット ファイルを作成しました。これが私がbatファイルに入れたコードです：

IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END

ビルド前に、bat ファイルを呼び出します。たとえば、次のようにします。

call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"

SOで、正しい構成ファイルをweb.config/app.configにコピーするbatファイルを見つけました。プリビルドでは、このバッチ ファイルも呼び出します。このバット ファイルのコードは次のとおりです。

@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2 
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same.  Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same.  Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.

ビルド前に、bat ファイルを呼び出します。たとえば、次のようにします。

call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config
于 2014-01-14T10:24:28.773 に答える