33

web.configさまざまなオフィスに複数の開発者チームがあり、プロジェクトとapp.configファイルの多数の構成設定にさまざまな値が必要です。

これらの構成ファイルは、賢明なデフォルト値のセットでチェックインしたままにしておきたいので、トランク/マスター ブランチをチェックアウトすることで、構成ファイルを探し回らなくても何かが機能します。

歴史的に、私たちは Subversion、特に TortoiseSVN を使用してきました。これにより、ローカルの変更を管理する簡単な方法が提供されました。これらのファイルを TortoiseSVN の自動変更リストに追加するだけですignore-on-commit。これにより、これらのファイルの偶発的なチェックインを防ぐことができます。これは、チェックインに含めるためにそれらを具体的に選択する必要があるためです (ローカル構成のノイズではなく、重要な変更をチェックインしていることを確認できます)。このアプローチの主な欠点は、構成ファイルが常に「変更された」ように見えるため、ローカルの変更があるかどうかを一目で知ることができないことです。

Git への切り替えを検討しており、最適なアプローチを見つけようとしています。

まず、他の StackOverflow の回答に既にあるもの:

オプション 1: xxx.sample ファイルをチェックインし、実際の構成ファイルを .gitignore します。これは、たとえば、この回答で推奨されています。これに関する主な問題は、構成ファイルへの変更が簡単に忘れられてしまうことです。2 つの異なる時点で: コミッターは、.sampleファイルに追加する必要がある変更を簡単に見逃す可能性があり、コンシューマー (特に継続的インテグレーション サーバー) は簡単に見逃す可能性があります。ファイルから.sampleローカル構成ファイルに組み込む必要がある変更。基本的に、それはあまり良い解決策とは思えません。

オプション 2: チェックインされた xxx.defaults ファイルと、定義されている設定を上書きする .gitignored xxx.local 構成ファイルを用意します。これは、例としてここで提供されます。ここでの問題は、標準の .Net 構成プロバイダーを使用して作業していることです。Mirosoft がすべての作業を既に行っているのに、まったく新しい設定読み込みフレームワークを実装したくありません。オプションのローカル オーバーライド ファイルを参照するように app.config および web.config ファイルを取得する方法を知っている人はいますか?

オプション 3: 開発者にローカル ブランチを保持してもらい、常にチェリー ピックまたはリベース ブランチを master にチェックインさせて、ローカル ブランチでの不要なコミットを常にバイパス/回避する: これは可能なワークフローとしてここで提供されています。変更の追跡 (すべてのチェックイン) の点でクリーンであることを高く評価します。チェックインのたびに必要なオーバーヘッドがかなりの量になります。それは大きな痛みです！

オプション 4: 構成ファイルをチェックインし、次のようにマークする: これは、--assume-unchangedここで可能なオプションとして提供されます。私が知る限りignore-on-commit、TortoiseSVN の変更リストと精神的に非常に似ていますが、コミット プロセスでこれらの「隠された」変更済みファイルが表示されない点が異なります。たとえば、TortoiseGit は「変更された」アイコン オーバーレイでファイルを表示しますが、コミット ダイアログではファイルがまったく表示されません。これは少し恐ろしいように思えますが、ここでも変更のチェックを忘れがちです。

私が見つけたすべてのオプションであるこれらのオプションを考えると、チェックインされた app.config/web.config ファイルにローカル構成ファイルをオプションで「含める」方法を本当に望んでいます2 ; これを行う方法、または私が見逃している他のオプションを知っている人はいますか? (カスタムの Xml マージ ビルド前の手順を検討したいという気持ちがかすかにあります...)

前述のとおり、まだ VS2008 を使用しているため、構成変換は使用できません。

更新：（削除されました、明らかに間違っていました）

更新 2:以前の更新と回答を削除しました。それはばかげていました/機能しませんでした。「私たちの」マージの後、反対方向の次のマージで、それらのファイルの「元の」バージョンが戻される (ローカル ブランチの変更が上書きされる) ことに気付きませんでした。興味のある方は編集履歴をご覧ください。この質問は相変わらずオープンです。

4

5 に答える 5

12

ConfigGenをご覧になることをお勧めします。私たちはすべてのプロジェクトでそれを使用しており、すべての開発者とすべての環境で驚異的に機能します。基本的には、マシン名と出力構成ファイルを示すスプレッドシートから実行され、テンプレート App.Config または Web.Config をトークン化し、スプレッドシートの値を代入します。configgen を実行する簡単なビルド前の手順をプロジェクトに追加すると、ビルドが開始される前に、マシン用に調整された構成ファイルが作成されます。また、デフォルト設定もサポートしています。

サイトを見て、自分で決めてください。しかし、私は間違いなくそれを保証できます.

編集:すべての Web.config および App.config ファイルを (.git に関して) 無視できることに注意してください。ただし、テンプレートとスプレッドシートをリポジトリに追加する必要があります。また、スプレッドシートの xml 置換を含む可能性のある更新が途中であると確信しています。これには独自のエディターがあり、DVCS に非常に適しています。

Edit2 :ダニエルの投稿もご覧ください: https://stackoverflow.com/a/8082937/186184 . 彼は、テンプレートとスプレッドシートの非常に明確な例と、それをソリューションで機能させる方法を示しています。

于 2012-05-08T07:37:36.673 に答える
7

コンテンツフィルタードライバーを検討しましたか？

コンテンツフィルターdfriver

つまり、それぞれgit checkoutについて、smudgeスクリプトは以下に基づいて実際の構成ファイルを生成します。

  • 構成テンプレートファイル（のような構成値プレースホルダーを@@A_PARAM_VALUE@@含む）
  • 構成値ファイルの1つ（各開発者は自分の構成ファイル値のバージョンを保持できます）

これにより、マージの問題とgitignore設定が回避されます。各「構成値ファイル」は異なり、別々のままです。これは、 pms1969の回答で言及されているConfigGen
の ような他の構成生成ソリューションとも互換性があります。

于 2012-05-13T13:04:21.397 に答える
1

潜在的な解決策については、Danによる展開環境間の複雑な Web.Config ファイルの管理に関するこの回答を参照してください。私はmercurialを使用し、これと同じプロセスを使用して一般的なweb.configファイルをチェックインし、Webトランスフォームを使用して配置固有のものを指すように場所を変更します。configSource

このルートを使用する利点は、フレームワークに完全に組み込まれており、追加のコードを必要とせず、Web デプロイで動作することです。

web.config でチェックイン:

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

web.debug.config でチェックイン:

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

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

于 2012-04-13T14:29:32.143 に答える
0

当社でも同様のジレンマに陥りました。最終的に、メイン ブランチを補足する個別の構成ブランチを作成しました。たとえば、develop-config、master-config などです。次に、展開環境に基づいて、これらのブランチを正しいソース ブランチにリベースする小さなスクリプトがあります。たとえば、開発マシンでは、develop-config を develop でリベースします。ローカル マシンで作業している場合は、メイン ブランチにチェックインされる既定の構成 (すべての開発者が同意) (ローカル DB 名、パスワードなど) を取得します。もちろん、マイナス面は、これらの *-config ブランチを常に最新の状態に保つか、展開時に最新の状態に保つ必要があることです。

このワークフローを実装して以来、whiskey_diskのような、いくぶん似たアプローチをとるいくつかの展開ツールに出くわしました。実際、私は彼らのソリューションがはるかに安全で柔軟であるため、はるかに気に入っています. LAMP/RoR 開発スタックを対象としているため、おそらく皆さんには適していません。

それとは別に、 Beanstalkのように検討したい商用ソリューションもいくつかあります。

于 2012-05-10T05:16:53.507 に答える
0

2012 年から少し変更があり、最近では環境固有の構成を管理するビルド/デプロイ ツール (VS Team Services、TeamCity、Octopus Deploy) をお勧めします。

Azure で作業している場合は、アプリの設定と接続文字列をアプリ定義の一部として定義できます。

于 2016-11-24T12:16:32.407 に答える