これが私が思いついた方法です：
私はいくつかのプロジェクトで（2）を使用しましたが、これは1台の開発マシンでうまく機能しましたが、現在は約10台であり、絶えず変化するリストの管理が難しくなる可能性があります。
（1）それは重要なファイルであり、バージョン管理されている必要があるため、私は好きではありません。
（3）試したことがない。各サーバーをセットアップするときに、より多くの構成が必要になりますが、それは問題のない解決策になる可能性があります。
私が逃した他のものはありますか？長所/短所は何ですか？
(3) サーバー上で追加の構成を必要とする必要はありません。代わりに、デフォルトでサーバー モードに設定し、開発マシンでさらに構成を行う必要があります。
一般に、私は常に開発マシンを特別なケースにし、リリース動作をデフォルトにしたいと考えています。唯一の注意点は、関連する設定が構成ファイルにある場合、開発者が変更されたバージョンのファイルを誤ってチェックインし続けることです。これは、バージョン管理システム (チェックイン フックなど) で回避するか、次のいずれかで回避できます。
個人的には、1 つの構成ファイルをロードするコードが既にあるという理由だけで、構成オーバーライド ファイルを使用することを好みます。別の構成ファイルを追加するのは非常に簡単なはずです。もちろん、環境を読み取ることはまったく難しいことではありません。これは別のメカニズムにすぎません。
一部の人々は、自分のプログラムが環境によって制御されることを本当に好みます (特に、スクリプトから実行するときにプログラムを制御したい場合)。脚本）。そのため、この設定だけでなく、その POV の環境を使用する価値があるかもしれません。
別の完全に異なるオプション: 適切な管理者権限でアプリにログインしている場合は、アプリ内で開発/リリース モードを構成可能にします。これが良いアイデアかどうかは、次のようなデバッグ ログ メッセージを書き込むような開発者がいるかどうかによるかもしれません。愚かすぎる。」その場合は、(a) アプリ管理者がデバッグ モードを有効にできないようにします (b) 開発者を再教育します。
他にもいくつかの可能性があります。
一部の組織では、あるネットワーク上に開発用マシンを保持し、別のネットワーク上に運用マシンを保持しています。たとえばdev.example.com、prod.example.com. 組織がその方法を使用している場合、アプリケーションは、それが実行されている完全修飾ホスト名を介して、またはおそらく IP アドレスの一部のビットを調べることによって、その環境を判別できます。
もう 1 つの可能性は、組み込み可能なスクリプト言語 (Tcl、Lua、Python が思い浮かびます) を構成ファイルの構文として使用することです。これは、構成ファイルが環境変数 (または IP アドレス) を簡単に照会し、それを使用してif-then-elseステートメントを駆動できることを意味します。このアプローチの欠点は、誰かが構成ファイルを編集して悪意のあるコードを追加する (ファイルを削除するなど) という潜在的なセキュリティ リスクです。
最後の可能性は、シェル/Python/Perl スクリプトを介して各アプリケーションを起動することです。スクリプトはその環境を照会し、それを使用してif-then-else、コマンドライン オプションを「実際の」アプリケーションに渡すためのステートメントを駆動できます。
ところで、環境テストif-then-elseステートメントを次のようにコーディングするのは好きではありません。
if (check-for-running-in-production) {
... // run program in production mode
} else {
... // run program in development mode
}
上記のロジックcheck-for-running-in-productionは、新しく追加された運用マシンを処理するためにテストが更新されていない場合、暗黙のうちに中断されます。代わりに、もう少し防御的にコーディングしたい場合:
if (check-for-running-in-production) {
... // run program in production mode
} else if (check-for-running-in-development) {
... // run program in development mode
} else {
print "Error: unknown environment"
exit
}