4

OK、それで私はばかげたことをして、開発データベース (SQL Server 2008 R2) を対象とする製品コード (C#、VS2010) をリリースしました。幸いなことに、まだ運用データベースを使用していないので、すべてを復元して同期するという苦労はありませんでした...

だけど、それ以上に苦しくなる可能性があるときに、このようなことが二度と起こらないようにしたい。私の考えは、起動時にクエリできるテーブルを追加し、返された値によって接続しているデータベースを判断することです。たとえば、本番環境では「PROD」が返され、開発およびテストでは他の値が返されます。

違いがある場合、アプリケーションはデータベースにアクセスするために WCF サービスと通信するため、実際の接続文字列ではなく、構成ファイルにエンドポイントがあります。

これは理にかなっていますか？他の人はこの問題にどのように対処しましたか?

ありがとう、デイブ

4

4 に答える 4

5

これを解決する最も簡単な方法は、本番アカウントにアクセスできないようにすることです。これらは、.net アプリケーションの Machine.config ファイルに保存されます。.net 以外のアプリケーションでは、構成ファイルを共通の場所に置くか、(あえて言うなら) アカウント情報を保持するレジストリ エントリを作成することで、これを簡単に複製できます。

ほとんどのサーバーはエイリアスを介してアクセスされるため、環境ごとに接続文字列を実際に変更する必要はありません。構成からユーザーを取得するだけで、hosts ファイルのサーバー エイリアスが正しいサーバーを指します。これにより、db インスタンスを切り替える (ハードウェアを変更するなど) ときに、すべての構成ファイルを更新する必要がなくなります。

そのため、クリック 1 回の展開とエンド ポイントでも同様です。エンド ユーザーのデスクトップのマシン構成で新しいエンドポイント URI を公開し (これは内部アプリケーションであると想定しています)、コードでそれを参照できます。

これは大変な作業になる可能性があるため、絶対にできない場合 (私が最後に働いた場所には 2000 人のコール センターのスタッフがいたため、このプッシュははるかに困難でしたが、それでも可能でした)。アプリケーションをビルドする最後のステップとして、app.config ファイルを変更する自動ビルド サーバー セットアップをいつでも行うことができます。次に、コンパイルされたコードを自動ビルド サーバーから常に公開します。このような app.config の変更は、開発者のプロセスにおける手動のステップではありません。これは常にある時点で問題を引き起こします。

これでうまくいかない場合は、最終的なオプション (これも実行) が嫌いでしたが、マップされたドライブから値を検索することでうまくいきました。基本的に、社内の全員が R: と言うドライブを割り当てられています。これは、本番構成ファイルなどがある場所です。本番アカウントの担当者は、本番用の値を持つドライブの場所にマップされ、開発者などは、開発用の値を持つ別の場所にマップされます。他のオプションと比較してこのオプションは嫌いですが、機能し、他の人が退屈で困難になるピンチであなたを救うことができます（オフィスの政治、ビルドサーバーのセットアップなどのために）。

于 2012-04-03T21:39:22.797 に答える
2

本番サーバーの名前は開発サーバーとは異なると想定しているため、単純にSELECT @@SERVERNAME AS ServerName.

于 2012-04-03T22:06:21.137 に答える
1

MSBuild と app.config の操作に関する教科書とチュートリアルを何時間も調べた後、SlowCheetah - XML Transforms http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5と呼ばれるものに出くわしました。最初に遭遇してから 1 時間もかからずに実行する必要がありました。絶対にお勧めです！記事から：

このパッケージを使用すると、ビルド構成に基づいて app.config またはその他の XML ファイルを変換できます。また、XML 変換の作成に役立つツールも追加されています。

このパッケージは、Sayed Ibrahim Hashimi、Chuck England、Bill Heibert (MSBuild に関する本を執筆したのと同じ Hashimi) によって作成されました。ビルド構成に基づいて app.config、web.config、またはその他の XML ファイルを変換するための簡単なユビキタスな方法を探している場合は、これ以上探す必要はありません。この VS パッケージがその仕事をします。

ええ、私は自分の質問に答えたことを知っていますが、最終的に本当の答えを示した答えにすでにポイントを与えました。ここで、問題の新しい理解に基づいて、戻って質問を編集する必要があります...

デイブ

于 2012-04-18T21:31:55.243 に答える
1

この回答が想定される .net 環境で役立つかどうかはわかりませんが、* nix/PHP 環境では、これが同じ状況を処理する方法です。

OK、私はばかげたことをして、製品コードをリリースしました

あなたが逃したように、一部のアプリの動作が環境に依存する場合があります。開発環境と本番環境をチェックするこの機能を提供するために、次の行をグローバル /etc/profile/profile.d/custom.sh config (CentOS) に追加しました。

SERVICE_ENV=dev

コードには、名前に基づいて環境変数を取得し、その値をローカライズして、アプリケーション コードにアクセスできるようにするラッパー メソッドがあります。以下は、現在の環境を確認し、それに応じて対応する方法を示すスニペットです (PHP で):

public function __call($method, $params)
{
    // Reduce chatter on production envs
    //  Only display debug messages if override told us to
    if (($method === 'debug') &&
        (CoreLib_Api_Environment_Package::getValue(CoreLib_Api_Environment::VAR_LABEL_SERVICE) === CoreLib_Api_Environment::PROD) &&
        (!in_array(CoreLib_Api_Log::DEBUG_ON_PROD_OVERRIDE, $params))) {
        return;
    }
}

スニペットで示されているように、いくつかの極端な使用例を除いて、アプリケーション ロジックに環境チェックを追加したくないことを覚えておいてください。むしろ、DNS を使用して本番データベースへのアクセスを制御する必要があります。たとえば、開発環境内では、次の db ホスト名mydatabase-dbは、実際の運用サーバーではなくローカル サーバーに解決されます。また、コードを本番環境にプッシュすると、DNS がホスト名を正しく解決するため、コードは環境チェックなしで「そのまま機能する」はずです。

于 2012-04-03T22:11:11.450 に答える