バージョン管理下でシステム固有の情報を処理するためのベストプラクティスは何ですか？

Question

バージョン管理は初めてなので、これに対するよく知られた解決策がある場合は謝罪します。特にこの問題では、gitを使用していますが、すべてのバージョン管理システムでこれに対処する方法について興味があります。

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

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

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

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

これを処理する最良の方法は何ですか？私は考えた：

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

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

3. バージョン管理外の設定ファイルからパスをプルします。次に、すべてのサーバーの同じ場所に構成ファイルを配置する必要があります。最初から同じパスを使用することもできます。

これに対処する簡単な方法はありますか？考えすぎですか？

Answer 1

ファイルシステムパスなどの構成データをハードコーディングしたり、複数の展開を一致させたりしないでください。それが暗い側面であり、そこでは多くの苦労があります。

複数の構成を簡単にサポートするためにシステムを構築するのが便利で簡単であることがわかり、構成ファイルをソース管理にサイドバイサイドで定期的にコミットしますが、本番は難読化され（実際のパスワードはありません）、開発はテンプレート化されています（そのため、チェックアウトは開発者の設定を上書きできません）。コードは常に構成に中立な方法でパッケージ化されます。同じバイナリをどこにでも展開できます。

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

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

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

構成アクセスを抽象化して、ほとんどのアプリケーションがどこから来たのか、どのように処理されたのかわからないようにします。構成可能な設定を個別のプロパティとして公開する Config クラスを作成することを好みます（関連する場合は強く入力します）。その後、「注入」します。それらをIOC経由でアプリケーションクラスに入れます。すべてのアプリケーションクラスで、選択したプラットフォームの未加工の構成フレームワークを直接呼び出さないでください。抽象化はあなたの友達です。

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

お楽しみください。

Answer 2

履歴管理（ソース管理の目的）は常に展開から分離する必要があります。

展開には次が含まれます：

• 識別されたデータのセット（SCMによって提供されるタグまたはラベルが役立つ）
• これらのデータを操作するプロセス（少なくとも適切な場所にコピーするだけでなく、圧縮ファイルを展開するなど）...

展開が行うさまざまな操作の中で、 de-variabilization フェーズを含める必要があります。

変数は、展開プラットフォームに応じて変化する可能性のあるものを表すキーワードです（継続的統合用のPC、基本的な認証用のlinux、運用前認証用の古いSolaris8、ゾーン付きのFull F15K Solaris10など）本番用：それは短く、それは大きく異なる可能性があります）。 ジョナサンレフラーの回答実用的な例。

変数はパス、JVMバージョン、いくつかのJVM設定などを表すことができ、SCMに入れるものは変数を含むデータであり、ハードコーディングされた設定ではありません。

次のステップは、一部のパラメーターの実行中に更新するために、設定ファイルの変更を検出する方法を実行可能ファイルに含めることです（すべての「シャットダウン/設定の変更/再起動」シーケンスを回避します）。
つまり、これらは 2種類の展開変数です：

• 静的のもの（決して変わらない）、
• 動的のもの（ランタイムセッション中に理想的に考慮されるべきもの）

Answer 3

可能な限り絶対パスを避けます。

現在のバージョン管理に頼って魔法のようなことをしないでください。将来バージョン管理システムを変更する可能性があります。

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

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

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

Answer 4

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

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

Answer 5

Ruby on Railsがこの種の問題（環境固有の構成ファイル）を処理する方法が気に入っています。 Railsは、database.ymlファイルの設定によって制御される、開発、テスト、および本番のデータベース接続をサポートします。他の環境固有の設定オプションの作成に関するブログ投稿があります。これはRails用ですが、環境に似た何かを行う方法についてのアイデアを提供するかもしれません。 http://usablewebapps.com/2008/09 / yaml-and-custom-config-for-rails-projects /

Answer 6

実動コードはgitリポジトリでいっぱいであるように聞こえますが、実動を更新するには git pull を実行しますか？リポジトリからコードをチェックアウトし、クリーンビルド（.gitフォルダーなし）を作成する別のビルドプロセスを試すことをお勧めします。一緒にコピーまたは作成されるパスを含む環境固有の構成ファイルを作成できます。