2012-04-03 9 views
4

OK、私はダムを行い、開発データベース(SQL Server 2008 R2)をターゲットとする製品コード(C#、VS2010)をリリースしました。幸運にも私たちは本番データベースをまだ使用していないので、すべてを回復して同期しようとする苦労はありませんでした...実行時に本番データベースに接続しているかどうかを確認する方法は?

しかし、私はもっと痛いかもしれません。私の考えは、私が起動時に照会できるテーブルを追加し、返された値によってどのデータベースに接続しているのかを判断することです。プロダクションは "PROD"を返し、devとtestは他の値を返します。

違いがあれば、アプリケーションはデータベースにアクセスするためにWCFサービスに伝えます。実際の接続文字列ではなく、設定ファイルにエンドポイントがあります。

これは意味がありますか?他の人がこの問題にどう対処したか

おかげで、 デイブ

+0

、あなたのテストにPRODからバックアップを復元するとき、それを更新するために思い出しているテーブルを使用しての一つの問題またはDEV環境とあなたがPRODを見たとき、あなたは –

+0

@Michaelいけないと思うとき怖がら - 美しく動作しますが、それはコメントだけだと私は答えとしてそれを受け入れることができない... – DaveN59

+0

DaveN59 @その場合、私は答えに私のコメントを変換しました... –

答えて

5

これを解決する最も簡単な方法は、生産アカウントへのアクセスを持っていないことです。それらは、.netアプリケーション用のMachine.configファイルに格納されています。非ネットアプリケーションでは、共通の場所に設定ファイルを置くか、アカウント情報を保持するレジストリエントリを(あえて言うと)簡単に複製できます。

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

クリックして一度だけの展開とエンドポイントでも。エンドユーザのデスクトップ上のマシンコンフィグレーションに新しいエンドポイントURIをパブリッシュすることができます(これは内部アプリケーションであると仮定しています)。

これは大変な作業です(私は2000年のコールセンターの従業員がいたので最後の場所だったので、このプッシュははるかに困難でしたが、まだ可能でした)。アプリケーションをビルドする最後のステップとして、app.configファイルを変更する自動ビルドサーバーのセットアップをいつでも行うことができます。その後、自動ビルドサーバーからコンパイルされたコードを常に公開します。 app.configの変更は、開発者の手作業で行うようなことは絶対にしないでください。これはいつか問題につながるでしょう。

これがうまくいかない場合は、私が嫌っていた最終オプション(これもあまりにも)を実行しましたが、マップされたドライブの値を調べることができました。本質的に、同社の全員が、R:と言うドライブを割り当てています。これは、プロダクション設定ファイルなどがある場所です。プロダクトアカウントの人は、プロダクション値を持つ1つのドライブの場所にマップし、開発者などは開発値を持つ別のドライブにマップします。私はこのオプションが他のものと比べて嫌いですが、それはうまくいきますし、他人が退屈で困難になることもあります(オフィス政治、ビルドサーバーの設定など)。

+0

私はここに当てはまるとは確信していません。すべてのユーザーは同じアカウント(生産ライン)を使用しており、Click Onceを使用して公開しています。また、WCFサービスについての私の後の編集を参照してください...私たちは実際に私たちのプロダクションサービスを打つコードを公開することができます。 – DaveN59

+0

+1エイリアスの場合... –

+0

あなたの思いやりのある答えに感謝します。私の最初の嫌悪感の一部は、私がmachine.configに慣れていないという事実に起因していました。私が見つけたことを掘り下げると、すべての関数は、System.ServiceModelを含まないconfigSections部分に含まれる設定に限定されているようです。だから、私は学習遠征に行きます...どんな速度でも、あなたはあなたがチェックを得るために最も完全な答えです。 – DaveN59

2

プロダクションサーバーの名前が開発サーバーの名前と異なると仮定しているので、単純にSELECT @@SERVERNANE AS ServerNameとすることができます。

+0

私はこれを実装しようと考えていますが、少し考えてから、これは最終的な解決策としては機能しません。それは私の元のアイデアのラインに沿って問題を解決しますが、私たちが台無しになったときにアプリケーションを失敗させるのは良いことではありません。ああ。とにかく、私はあなたが本当にうまくいけば私たちをつかまえるフェイルセーフとしてあなたの提案を実装するつもりですが、問題の解決策ではありません。提案していただきありがとうございます! – DaveN59

1

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

OK、私はあなたに逃れたとして、いくつかのアプリの動作は、環境に依存している時間があり、ダムの事と解放生産コード

をしました。開発環境と本番環境の間で確認するには、この機能を提供するために、私はグローバル/etc/profile/profile.d/custom.shの設定(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を使用して運用データベースへのアクセスを制御する必要があります。たとえば、開発環境内で次のデシベルのホスト名mydatabase-dbではなく、あなたの実際の運用サーバーのローカルサーバーに解決されます。また、コードを運用環境にプッシュすると、DNSがホスト名を正しく解決するため、コードは環境チェックを行わずに「うまく動作する」必要があります。

1

MSBuildとapp.configの操作に関する教科書やチュートリアルを何時間も過ごしてから、私はSlowCheetahと呼ばれるものを見つけました。http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5これは最初に遭遇した後1時間もかかりませんでした。間違いなくお勧め!記事から:

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

このパッケージは、サイード・イブラヒムHashimi、チャックイングランドとビルHeibert、MSBuildの上で本を執筆同じHashimiによって作成されます。あなたのapp.config、web.configファイルまたはビルド構成に基づいて、他のXML FIEを変換するための簡単なユビキタスな方法を探しているなら、もう探す必要はありません - このVSパッケージは、仕事を行います。

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

デイブ

+0

SlowCheceがあなたのために働いてくれたことをうれしく思っています。 –

関連する問題