6

私はバージョン管理が初めてなので、これに対するよく知られた解決策があればお詫びします。特にこの問題については git を使用していますが、すべてのバージョン管理システムでこれをどのように処理するかについて興味があります。

開発サーバーで Web アプリケーションを開発しています。2 つの場所で (ドキュメント ルートではなく) Web アプリケーションへの絶対パス名を定義しました。運用サーバーでは、このパスは異なります。私はこれに対処する方法について混乱しています。

次のいずれかが可能です。

  1. 開発サーバーを再構成して、本番サーバーと同じパスを共有する
  2. プロダクションが更新されるたびに、2 つのオカレンスを編集します。

将来の変更に備えてアプリケーションを柔軟に保ちたいので、#1 は好きではありません。3 番目のパスを持つ 2 番目の開発サーバーで開発を開始すると、コミットと更新のたびにこれを変更する必要があるため、#2 は好きではありません。

これを処理する最善の方法は何ですか? 私は考えました：

  1. カスタム キーワードと変数展開の使用 (バージョン管理プロパティでプロパティ $PATH$ を設定し、すべてのファイルで展開するなど)。パフォーマンスに大きな影響を与えるため、Git はこれをサポートしていません。

  2. 更新後フックとコミット前フックの使用。おそらくgitの解決策ですが、ステータスを見るたびに、2つのファイルが変更されていると報告されます。本当にきれいではありません。

  3. バージョン管理外の構成ファイルからパスをプルします。次に、構成ファイルをすべてのサーバーの同じ場所に配置する必要があります。最初から同じ道をたどればよいのです。

これに対処する簡単な方法はありますか？私はそれを考えすぎていますか？

4

6 に答える 6

12

ファイル システム パスなどの構成データをハードコーディングして、複数の展開を強制的に一致させないでください。それは多くの苦しみがあるダークサイドです。

複数の構成を簡単にサポートするようにシステムを構築するのは便利で簡単だと思います。また、定期的に構成ファイルをソース管理に横に並べてコミットしますが、本番環境は難読化されており (実際のパスワードはありません)、開発環境はテンプレート化されています (チェックアウトができるように)。開発者の構成を上書きしないでください)。コードは常に構成に依存しない方法でパッケージ化されます。同じバイナリをどこにでもデプロイできます。

残念ながら、ほとんどの言語/開発プラットフォームはこれを容易にサポートしていません (Ruby on Rails とは異なります)。したがって、さまざまな程度で、自分で構築する必要があります。

一般に、基本的な原則は、構成に間接性を組み込むことです。構成を指定するのではなく、構成を見つける方法をコードで指定します。そして一般的に、ユーザー固有、アプリケーション固有、マシン固有、環境固有のいくつかの間接化を呼び出します。それぞれが明確に定義された場所/方法で見つかる必要があり、それらの間に非常に明確に定義された優先順位がある必要があります (通常、環境よりもアプリケーションよりもマシンよりもユーザーが優先されます)。通常、すべての構成可能な設定には 1 つの場所に自然なホームがありますが、その依存関係をアプリケーションにハードコーディングしないでください。

構成を報告し、それを検証できるようにアプリケーションを設計することは非常に価値があると思います。ほとんどの場合、設定項目が見つからないか無効であると、アプリケーションが中止されます。可能な限り、起動時にその検証 (および中止) を実行する = フェイル ファスト。確実に使用できる場合にのみ、デフォルトをハードコードします。

構成アクセスを抽象化して、ほとんどのアプリケーションがアクセス元や処理方法を認識できないようにします。Config私は、構成可能な設定を個別のプロパティ (関連する場合は厳密に型指定) として公開するクラスを作成し、IOC を介してそれらをアプリケーション クラスに「注入」することを好みます。すべてのアプリケーション クラスが、選択したプラットフォームの raw 構成フレームワークを直接呼び出さないようにしてください。抽象化はあなたの友達です。

ほとんどのエンタープライズ クラス (Fortune 500) の組織では、その環境の管理チームを除いて、誰も運用 (またはテスト) 環境の構成を見ることはありません。構成ファイルはリリースに展開されることはなく、管理チームによって手動で編集されます。関連する構成ファイルがコードと並んでソース管理にチェックインされることは決してありません。管理チームはソース管理を使用する場合がありますが、それは独自のプライベート リポジトリです。Sarbanes-Oxley および同様の規制も、開発者が (ほぼ) 実稼働システムまたは機密の構成データに一般的にアクセスすることを厳しく禁止する傾向があります。アプローチを設計するときは注意してください。

楽しみ。

于 2009-01-07T06:44:24.367 に答える
2

絶対パスはできるだけ避けてください。

何か魔法のようなことをするために、現在のバージョン管理に頼らないでください。将来、バージョン管理システムを変更するかもしれません。

最も簡単なアプローチは私にとってはうまくいきます.「config.live」があり、「config」は開発用に構成されています. 展開中に config.live を config に移動するだけで問題ありません。より複雑な構成では、構成ごとにサブディレクトリが必要になる場合があります。

構成は異なる 1 つの領域にすぎないため、一連の展開手順が不可欠です。

より複雑なものは、ほぼ確実に、解決するよりも多くの問題を引き起こす可能性があります。

于 2009-01-07T06:55:36.170 に答える
1

バージョン管理には Git などの SCM を使用し、展開には Capistrano などの展開ツールを使用します。Capistrano は当初、Ruby on Rails 用に作成されましたが、他のフレームワークや言語に使用してもまったく問題ありません。

主なことは、特定の展開ツールを使用すると、両端でパスなどを自動化するためのすべての柔軟性が得られることです。

于 2009-01-07T08:17:16.567 に答える
0

あなたの製品コードは git リポジトリでいっぱいで、製品を更新するにはgit pull? リポジトリからコードをチェックアウトし、クリーン ビルド (.git フォルダーなし) を作成する別のビルド プロセスを試してみることをお勧めします。一緒にコピーまたは作成されるパスを含む環境固有の構成ファイルを持つことができます。

于 2009-01-07T06:38:53.410 に答える