Subversion は、サーバー上の Web アプリケーションを更新する優れた方法です。単純に、svn updateすべての変更されたファイルが取得されます...まあ、変更されました。
config.phpデータベースアクセス構成、サーバーパスなどを保持するような遍在する構成ファイルを除いて。したがって、ローカル開発システムとリモートサーバーでは異なります。
このupdateコマンドでは、サーバー上で変更されたファイルは上書きされませんが、ファイルをローカルで変更してコミットすると、サーバーは間違った構成ファイルを取得します。
svn:ignoreただし、構成ファイルはプロジェクトに属しているため、プロパティも設定したくありません。
これらの種類のファイルを簡単に処理できる Subversion メカニズムはありますか? または、この問題を解決する唯一の方法は、実行中のシステムを決定し、それに応じて構成を設定する構成ファイル内でシステム スイッチを作成することですか?
ファイルのテンプレート (例: config.php-default) を作成し、ユーザーがテンプレートをコピーできるようにします。また、差分を作成してバージョン間で何が変更されたかを確認し、これらの変更をローカルに展開されたバージョンのファイルに組み込むこともできます。
開発者が本番マシンのユーザー名/パスワードにアクセスできない（そしておそらくそうすべきではない）という事実を考慮したいと思うかもしれません。
これに対処するには、このような構成は、アプリケーション全体の構成ではなく、「デプロイメントの詳細」と見なす必要があります。この概念を区別する場合でも、さまざまなデプロイメント環境に対処する必要がありますが、PHPを扱っているように見えるため、ケースの詳細についてコメントすることはできません。
Larsが述べたように、考えられるJ2EEソリューションの1つは、そのような詳細をJNDIに格納し、まったく同じアプリケーションバイナリを任意の環境にデプロイできるようにして、DBA/管理者が各マシンのユーザー名/パスワードを設定できるようにすることです。
考えられる解決策:
J2EE アプリケーション サーバーを使用している場合は、JNDI を介してプロパティを検索できます。サーバー上でプロパティを簡単に設定および表示するためのツールがあります。
Subversion サーバーにデフォルトのプロパティ ファイルを設定できますが、実際のプロパティ ファイルをサーバーの別の場所 (svn にチェックインされているプロジェクトの部分以外) で探すことができますが、通常は OS に依存するパスを取得するため、覚えておく必要があります。 svn ファイルに新しいプロパティを追加するときに、実際のプロパティ ファイルを手動で更新します。
ビルドの一部としてプロパティー・ファイルにプロパティーを設定し、ビルド・コマンドにパラメーターを渡して、ビルド対象のサーバー環境を指示できます。これは少し遠回しに感じるかもしれません。新しいプロパティでビルド スクリプトを更新することを忘れないでください。しかし、それはうまく機能します - 継続的インテグレーション サーバーを設定すると、すべての異なる環境用にビルドし、バンドルをテストすることができます。次に、展開の準備ができていることがわかります。
最も簡単な方法は、マシンのホスト名をオンにすることです。本番、テスト、および開発システム用にこれをオーバーライドする一般セクションを含む .ini ファイルがあります。
[general]
info=misc
db.password=secret
db.host=localhost
[production : general]
info=only on production system
db.password=secret1
[testing : general]
info=only on test system
db.password=secret2
[dev : general]
info=only on dev system
db.password=secret3
したがって、dev:db.password == 'secret3' ですが、元の 'general' グループから dev:db.host == 'localhost' になります。
「production」、「testing」、および「dev」は、マシンのホスト名であるか、構成制御スクリプトの他のメカニズムから設定されたエイリアスです。
私が現在取り組んでいるプロジェクトでは、データベース スキーマ情報用に 2 つのプロパティ ファイルがあります。1 つは運用環境用、もう 1 つは開発用です。実行中のモジュールのすべてのプロパティをロードするクラスがあり、ロードするファイルを決定するロジックがあります。
ローカルの開発環境は Windows ファイル システムであり、運用サーバーは UNIX ファイル システムで動作するため、解決策はホストのオペレーティング システムを特定し、正しいファイルをロードすることでした。
行われた変更の履歴を保持するために、これらをソース管理内に直接保持します。ファイルに対する過去の変更を防御できるようにする必要があるという点で、INSANELY FREQUENT REQUIREMENTS CHANGESに関して (内部) クライアントの指差しから教訓を学んだと思います。
これは私たちの状況に固有のものかもしれませんが、特に以前のリビジョンからテスト実行を複製しようとしている場合、これは非常に役立つことがわかりました.
構成ファイルのドメインを依存させることもできます。このようにして、ローカル マシンと運用サーバーの構成を作成できます。もちろん、これを処理するにはロジックを構築する必要があります。
Apache Web サーバーを実行すると、すべての開発者が localhost を使用する代わりに、ローカル ボックスで独自の (サブ) ドメインを使用するように簡単に構成できます。このようにして、すべての開発者が独自の構成を使用できます。