4

この件に関するいくつかのチュートリアルを読みましたが、ZF2 アプリ環境を認識させたい開発者から期待されることをまだ完全には理解していません。

http://blog.evan.pro/environment-specific-configuration-in-zend-framework-2
http://www.spiffyjr.me/2012/06/17/how-does-configuration-work-in-zf2 /コメントページ-1/

ZF2 は設計上、環境の概念を認識していません。実装は開発者に任されています。それがどのように行われることになっているのか、私は完全に明確ではありません...

Evan の投稿を読むと、2 つのメカニズムがあるように見えます。推奨されるのは、 APPLICATION_ENV 定数を使用せず、.local、.global ファイルのみを使用することですか?

それはどのように機能しますか？ZF2環境を認識させるために行ったプロセスについて説明してもらえますか? また、コードを別の環境にプッシュする場合はどうしますか?

例として、 module1.local.php.dist-testing、module1.local.php.dist-production、module1.local.php.dist-development、およびコードが別の環境に移動されたときのアイデアが今のところあるようですこれらはその環境に合わせてコピーの名前を変更し、パスワードを手動で入力する必要があるという考えですか? 私は正しいですか？

4

1 に答える 1

7

アプリケーションに適切なデフォルト設定を提供するが、コードやバージョン管理システムには具体的な環境用に何も保存しないという考え方です。

たとえば、2 つのサーバー (1 つは運用用、もう 1 つは開発用) がある場合、そのような .local ファイルで 1 つの環境の構成の詳細のみを提供します。このようにして、開発サーバーは本番データベースのマスターパスワードなどを知ることができません。したがって、新しい開発サーバーを取得したときに、だれかが APPLICATION_ENV を設定するのを忘れて、アプリケーションがパスワードを知っているため、開発を開始して実稼働データベースを台無しにするということが偶然に起こることはありません。

またはその逆で、新しい運用サーバーが誤って開発データベースにアクセスすることはありません。

したがって、アプリケーションは、存在するファイルを読み取ることによって環境を自動的に認識します。すべての詳細を含むファイルは、存在する環境ごとに 1 つだけ存在します。

これにより、正しいファイルが管理者 (またはすべてを構成する puppet スクリプト) に存在することを確認するという負担が生じます。ただし、環境固有の構成はアプリケーション内にデプロイされません。

于 2012-12-05T22:36:26.793 に答える