私は、本番、テスト、および開発用のブランチを持つ、Webとクライアントを組み合わせたアプリに取り組んでいます。svn post commitフックを使用して、本番サーバーとテストサーバーに更新をデプロイしています。クライアントアプリは、本番、テスト、または開発に応じて異なるURLを指す必要があります。Subversionを使用してこれを管理するにはどうすればよいですか？私が考えたオプションは次のとおりです。
オプション1
ブランチ間でマージされないブランチ固有の詳細を含むファイルを保持します。
このオプションは、ビルド管理の観点からは簡単ですが、マージが実行されるたびにその変更を無視することを忘れないようにする必要があるため、エラーが発生しやすくなります。
オプション2
どのブランチに関係なく、クライアントの本番ビルド、テストビルド、および開発ビルドを作成し、svnフックを使用して正しいバイナリをプルダウンします。
これをどのように処理しますか？より良いアイデアはありますか？
私たちのアプリケーションは、デプロイされた環境ごとに構成ファイルを含む個別のディレクトリを保持します。ビルド サーバーは、特定の環境にデプロイするタスクを実行するときに、構成ファイルをプルするディレクトリを認識します。正しいディレクトリへのポインターは、ビルド サーバー (この場合は Pulse) のビルド定義の一部です。その Pulse タスクのコードがどのブランチから構築されるかも、タスク仕様の一部です。これにより、展開サーバーの決定がブランチから独立して行われるため、新しいバージョンのサーバーとデータベースをリリースすると、別の目的で使用できるようになります。
+ dev-server
+---jdbc.properties
+---build.properties
+ test-server
+----jdbc.properties
+---build.properties
構成ファイルは、アプリケーションの残りの部分 (トランク、ブランチなどの兄弟) とは分岐していません。それらは svn ツリーに独自の場所があり、Subversion の外部定義として各ブランチに取り込まれます。
各ブランチにはそこからデプロイされた多くのサーバー (開発、テスト、ビルド、自動化など) があるため、このようにします。
私の好みは、プロジェクト固有の構成ファイルをソース管理にチェックインするのではなく、環境変数の内容とその他の構成要素を共通フォルダー (ソース管理内) に保持することです。次に、構成ファイルは、特定のプロジェクト、ソリューション、環境が特定の時点で必要とするものに応じて、ローカル ビルド、ビルド自動化、または展開スクリプトの一部として生成されます。これは、必要に応じて、単純なテキスト ファイル、xml テンプレート、または Spark ビュー エンジンのようなより複雑なものを使用して実行できます。テンプレート化が必要以上に複雑な場合 (通常はそうです) は、規則に従ってこれを行うこともできます。このようにして、コードをデプロイする場所に関係なく、環境固有の構成を定義できます。
規則による例は、プライマリ構成ファイル (Web 構成、アプリ構成など) でカスタム構成セクションを定義することです。その後、connection-strings-development.config、connection-strings-integration.config、connection-strings-testing.config、connection-strings-pre-production.config、および connection-strings-production を保存できます。 config をプライマリ ソース (または共通フォルダー) に配置します。ビルド プロセスは、適切な接続文字列構成ファイルを削除し、名前を単純に connection-strings.config に変更します。
テンプレートで生成すると、同じ環境固有の構成ファイルを持つカスタム構成セクションも作成されますが、展開時に名前を変更する代わりに、基本構成ファイルのセクションを適切な構成ファイル名で直接書き換えることができます。
ただし、構成ファイルを環境ごとにまとめておくと、特に同じまたは類似の構成スタイルを使用する多くのサイトの管理を開始した場合に、大きな柔軟性が得られます。ただし、構成は、自動化された環境のいくつかの側面によって決定される必要があります。