私は、開発/テスト/本番環境用のサブバージョン システムを構築する任務を負っていますが、同様の環境や提案に関する経験があるかどうか疑問に思っていました。
サードパーティ製品のスクリプトと複雑な構成ファイルを組み合わせた多数のシステムを構築および構成します。このため、サード パーティのシステム コードを制御できないため、構成ファイルとパスのレイアウトを再構築することはできません (つまり、システムが特定の場所に構成ファイルを配置する必要がある場合、そこに配置する必要があります)。
私たちは開発/テスト/本番の方法論を使用していますが、それよりも少し複雑です。各ステージには完全な物理環境があります。このため、各ステージは、その環境で機能するように変更する必要があります。すべての開発は開発サーバーで行い、テスト サーバーでテストしてから、運用サーバーを用意する必要があります。
このセットアップでは、プロジェクトのコピーを自分のワークステーションにチェックアウトして変更を加え、テストし、コミットして戻すことはできません。このようなものは、dev/test/prod サーバーでのみ機能します (つまり、特定のホスト名と IP 範囲に関連付けられています)。
したがって、私が見ているように、2つのオプションがあります。
オプション1
通常のトランク/ブランチ/タグ構造を行います。次に、開発/テスト/本番環境に固有のすべての変更を行うビルドの一部としてスクリプトを作成します。
たとえば、いつものようにすべてのコードをトランクにコミットし、満足したらリリース タグにコピーします。次に、テスト環境で latest タグをチェックアウトします。これには「セットアップ」スクリプトが含まれます。
次に、スクリプトを手動で (または SVN フックを介して) 実行すると、テスト サーバー上にいることが検出され、それに応じて変更が行われます。
この方法の問題は、svn diff などで、変更されたファイルへの変更が表示されることです。利点は、(かなり) シンプルであることです。
オプション 2
test/prod ブランチとトランクを開発として作成します。
project
trunk
branches
test
prod
tags
v1.0
v1.1
開発サーバーが を指しているという考えtrunkです。変更に満足したら、新しいタグを作成します。次に、それを にマージしbranches/testます。これには、テスト サーバーで動作させるために必要な変更が既に含まれています。テストが完了したら、prod に対して同じことを行います。
私が見る限り、このアプローチの利点は、派手なフック スクリプトが必要ないことです。また、dev/test と dev/prod の間に、SVN がマージによってより適切に処理できるはずの、より複雑な違いを持たせることができます。
いくつかの入力、提案、経験などを探しているだけです。私たちは Subversion に縛られており、残念ながら追加のツールは使用できません。
ありがとうございます（長々とすみません）！