gitのweb.configとapp.configのマシン固有の設定

Question

異なるオフィスに複数のチームの開発者がいて、プロジェクトのweb.configとapp.configファイルのいくつかの構成設定に異なる値が必要です。

これらの設定ファイルをチェックしておくと、デフォルト値がわかります。trunk/masterブランチをチェックすると、設定ファイルを掘り下げる必要がなくなります。

歴史的には、Subversion、特にTortoiseSVNを使用しています。これにより、ローカルの変更を簡単に管理することができました。これらのファイルをTortoiseSVNの自動ignore-on-commitチェンジリストに追加するだけです。これにより、これらのファイルが誤ってチェックインされるのを防ぐことができます。チェックイン時にそのファイルを指定する必要があります（ローカルの設定ノイズではなく、大幅な変更をチェックすることができます）。このアプローチの主な欠点は、設定ファイルが常に「変更された」ように見えるため、ローカルで変更があるかどうかを一目で知ることは不可能です。

私たちはGitに切り替えることを検討しています。私は最良の方法を見つけようとしています。

まず第一に、StackOverflowの他の回答であり、すでに何：

オプション1：xxx.sampleファイルにチェックして、実際の設定ファイルにを.gitignore：これはthis answerで、例えば、推奨されます。コミット者は.sampleファイルに追加する必要がある変更を簡単に見逃す可能性があり、コンシューマ（特に継続的な統合サーバ）は簡単に変更できないことがあります.sampleファイルからローカルの設定ファイルに組み込む必要がある変更がありません。基本的に、それは非常に良い解決策のようには見えません。

オプション2：持ってチェックインされたxxx.defaultsファイルとそれが定義する任意の設定を上書きします.gitignored xxx.local設定ファイル：これはアップ提供され、FRたとえば、here。私たちが標準の.Net設定プロバイダを使って作業しているという問題があります。Mirosoftが既にすべての作業を終えたときに、全く新しい設定ロードフレームワークを実装することは本当にありません。オプションのローカルオーバーライドファイルを参照するapp.configファイルとweb.configファイルを取得する方法を知っている人はいますか？

オプション3：開発者がローカルのブランチを維持しており、その後、彼らは常に、常にバイパス/地元の支店に不要なコミットを避けるために、マスターにチェリーピックやリベース支店にチェックインしている：これは可能性として提供されていますワークフローhereと、変更トラッキング（チェックインされたものすべて）の清潔さに感謝しますが、かなりの量のが必要です。すべてのチェックインには、オーバーヘッドが必要です。それは大きな痛みです！

オプション4：設定ファイルは、チェックインしましたが、それらは--assume-unchangedが付いている：これは、可能なオプションhereとして提供されています。あなたがTortoiseSVNのチェンジリストignore-on-commitと似ていますが、コミットプロセスでこれらの "隠された"変更されたファイルが表示されていないことを除けば、例えば、TortoiseGitは、ファイルに "変更された"アイコンオーバーレイを表示しますが、コミットダイアログではファイルはまったく表示されません。これはちょっと恐ろしいように思えますが、やはり変更を忘れてしまいます。

私が見つけたこれらすべてのオプションがあれば、チェックインされたapp.config/web.configファイルにローカルの設定ファイルをオプションで "含める"ことを望んでいますオプション2としてください。誰かがこれを行う方法、または私が行方不明の他のオプションを知っていますか？ （私はかすかにカスタムXMLマージ前のビルドステップを検討するように誘惑されています...）

私は以前に説明したはずですが、私たちはまだVS2008にいるので、構成変換は利用できません。

---

UPDATE：（削除、平野間違っていた）

UPDATE 2：私は私の以前の更新との回答を削除した、それは愚かだった/動作しませんでした。私たちが "私たち"がマージした後、他の方向の次のマージがそれらのファイルの "元の"バージョンを戻す（ローカルブランチの変更を上書きする）ことはわかりませんでした。興味がある場合は編集履歴をご覧ください。この質問はこれまでどおりに開いています。

Answer 1

this answer for Managing complex Web.Config files between deployment environmentsをDanで解決する可能性があります。私は水銀を使用し、これと同じプロセスを使用して一般的なweb.configファイルをチェックインし、Webトランスフォームを使用してconfigSourceの場所を自分の展開固有のものを指すように変更します。

このルートを使用する利点は、フレームワークに完全に組み込まれており、余分なコードを必要とせず、Webデプロイメントでも機能することです。

web.configファイルにチェック：

web.debug.configにチェック

<?xml version="1.0"?> 
<configuration> 
    <!-- snip --> 
    <connectionStrings configSource="config/connectionStrings.config" /> 
</configuration> 

：

<?xml version="1.0"?> 
<configuration> 
    <connectionStrings 
     configSource="config/dev.connectionStrings.config" 
     xdt:Transform="Replace(configSource)" /> 
</configuration> 

私はconfig/connectionStrings.configはデフォルトでチェックインしたが、開発サーバがconfig/dev.connectionStrings.configがチェックインされていません新しい展開では置き換えられません。

Answer 2

ConfigGenをご覧ください。私たちはすべてのプロジェクトでこれを使用し、すべての開発者にとって、そしてすべての環境でも不思議に思っています。基本的には、マシン名と出力設定ファイルを記述したスプレッドシートから実行され、App.ConfigまたはWeb.Configというテンプレートがトークン化され、スプレッドシートの値がそこに置き換えられます。あなたのプロジェクトにconfiggenを実行するための簡単なビルド前のステップを追加して、ビルドが始まる前に、あなたのマシン用のカスタマイズされた設定ファイルを用意してください。また、デフォルト設定もサポートしています。

サイトを見て、自分のことを考えてみてください。しかし、私は確かにそれを保証することができます。

EDIT：すべてのWeb.configファイルとApp.configファイルを（.gitに関して）無視することはできません。しかし、テンプレートとスプレッドシートをレポに追加する必要があります。また、スプレッドシートのxml置換が含まれている可能性があるため、DVCSに適したものになっています。

編集2：ダニエルの投稿をこちらからご覧ください：https://stackoverflow.com/a/8082937/186184彼は、テンプレートとスプレッドシートの非常に明確な例と、あなたのソリューションでそれを動作させる方法を示します。

Answer 3

私たちも同様のジレンマに遭遇しました。私たちは、メインブランチを補完する別々の設定ブランチを作成しました。たとえば、-development-config、master-configなどのように、デプロイメント環境に基づいて適切なソースブランチを持つブランチをリベースする小さなスクリプトを作成します。たとえば、開発マシンでは、開発用にconfigをrebaseします。ローカルマシンで作業している場合、メインブランチ（ローカルDB名、パスワードなど）にチェックインされているデフォルト設定（すべての開発者が合意）を取得します。もちろん、欠点は、* -configブランチを常に最新の状態に保つか、または展開時に速度を上げる必要があることです。

このワークフローを実装して以来、幾分似たアプローチをとっているwhiskey_diskのようないくつかのデプロイメントツールが出てきました。実際、私は彼らのソリューションがはるかに安全でフレキシブルなので、もっと好きです。おそらくLAMP/RoRの開発スタックに向けて調整されて以来、皆さんには適していませんが。それはさておき

、いくつかの商用ソリューションは、あなたがBeanstalk

Answer 4

のようなを見てみたいかもしれないとそこにもありますがcontent filter driverを検討しましたか？意味し、各git checkoutに、汚れスクリプトはに基づい実際の設定ファイルを生成する

：（ @@A_PARAM_VALUE@@ような設定値のプレースホルダを有する）

• 設定テンプレートファイル
• 設定値ファイルの1つ（各開発者は、自分の設定ファイル値をバージョン管理することができます）

マージ問題とgitignore設定を避ける：それぞれの「設定値ファイル」は異なっていて、別々のままです。
pms1969のanswerで言及されているConfigGenのような他の設定生成ソリューションと互換性があります。

Answer 5

2012年以降、少し変わってきましたが、今はビルド/デプロイメントツール（VS Team Services、TeamCity、Octopus Deploy）が環境固有の設定を管理することをお勧めします。

あなたが紺碧で作業している場合は、アプリケーション設定と接続文字列をアプリケーション定義の一部として定義できます。