私は、4 人の小さなチームのために、堅実な SVN リポジトリ構造と分岐戦略を考え出そうとしています。常に 4 つのメジャー プロジェクトといくつかのマイナー プロジェクトが開発中であり、プロジェクト間で重複することがよくあります。私たちの現在の戦略は完全に非効率的であり、これらの各フォルダー (約 15 程度) を 1 つのバージョン管理された「トランク」フォルダーの下に配置することで構成されています。これは、分岐するたびに、15 のプロジェクトすべてを分岐することを意味します (作業コピーを更新して分岐をプルダウンし、全体像を把握するのに約 20 分かかります)。
主な懸念事項は、一部のプロジェクトが重複していることです。機能やタスクがプロジェクト A とプロジェクト B で何かを変更する必要があることは珍しくありません (これらのプロジェクトはすべて同じデータベースと通信し、同じデータベース テーブルを使用します。さらに、プロジェクトはすべて、基本的に 1 つの「傘」アプリケーションの関連部分であるため、1 つのプロジェクトでクラスを変更すると他のプロジェクトに影響を与えるように、ビジネス層を共有します。例として、主要なプロジェクトには基本的に次のようなものがあります。
- プロジェクトA：フロントエンドECサイト
- プロジェクト B: バックエンド フルフィルメント/管理システム
- プロジェクト C: フロントエンド サイトのノーブランド コピー (同じものから CSS スタイルを除外し、機能を減らしたもの)
- プロジェクト D: Web サービス API
A と B は絡み合っていますが、B はサービスとしてのソフトウェア アプリケーション (当社が独自のクライアントとして機能) であり、C は顧客のフロント エンドです (A は自社のフロント エンドとして機能します。C は本質的に機能が少なく、会社固有の詳細がない)。D はクライアントのみがアクセスしますが、私の最終的な目標は、A、B、および C のすべてが Web サービスを介して D の機能を使用することです (基本的には、私たち自身のドッグフードを食べます)。
3 週間の展開戦略 (3 週間ごとに運用展開を行うことを意味します) を使用することを決定したところですが、現在の SVN 戦略は扱いにくく、分岐が非常に苦痛になります。
複数のプロジェクトが重複している場合、それらすべてをブランチ/タグ/トランク形式の 1 つのプロジェクト フォルダーに保持することは理にかなっていますか?それとも、それらを個別のプロジェクトとして扱うべきですか? たとえば、SaaS のフロントエンド/バックエンドを一緒にして、独自のサイトと Web サービスを分離するなど、いくつかを組み合わせることができますか?
同様のプロジェクトに携わる人々からの提案やアドバイスは素晴らしいものです。