1

いくつかの既存のインフラストラクチャ アセンブリを既存のアプリケーションと共有し、既存のドメイン モデルの重要なサブセットも含む、新しいアプリケーションのプロトタイプ作成を開始しようとしています。

ドメインモデルの一部は、この新しいアプリケーションのためにいくつかの重大な変更を受ける可能性があり、新しいアプリケーションが完全に仕様化され、ローンチの準備が整ったら、これらすべての最終的なゲームは、 2 つのアプリケーション (データベース、リンク機能などを共有するだけでなく) を使用しますが、開発やプロトタイピングなどの期間中は、別のデータベースを使用して、開発や使用への影響を心配することなく物事を変更できるようにします。既存のアプリケーション。これはプロトタイプであるため、さまざまなワークフローを使用した製品管理の実験、さまざまな顧客ベースの調査など、深刻な変更や再構築が発生する可能性があるかなり長い期間があり、私たちはそれに追いつくよう努めています.

成熟したアプリケーションでの並行開発に影響を与えないように、既に Subversion ブランチを作成しており、これを進めるための 2 つの方法を試しています。

  1. 分離の唯一のメカニズムとして svn ブランチを使用します。既存のドメイン モデルに変更を加え、既存のアプリケーションへの影響を評価します (また、ProjectA に必要な変更を加えます)。長期にわたって実行されているサイド ブランチが、トランクに再エントリするのに十分安定していることを確認します。

  2. 共有コードを (一時的に) "フォーク": ProjectA.Entities を NewProject.Entities にコピーし、すべての NewProject コードを自己完結型として扱います。モデルに関するすべての混乱が収まり、私たちが満足していると感じたら、手動で変更を ProjectA.Entities に再統合し (必要に応じて粒度またはスイープとして)、各ステップで改善されたモデルを使用するように ProjectA を更新します (これには時間がかかる場合があります)。サブバージョンのマージが発生する前または後に配置します)。Subversion マージは、ここでの大きな変更の再結合を処理しません。注: 「フォーク」メソッドは、大幅な変更が保存されているコードにのみ適用され、その変更により ProjectA が壊れます。たとえば、共有インフラストラクチャのものは、その場で (ブランチで) 変更し、マージを整理します。 .

  3. 開発は難しい、買い物に行く。

当然、合意に達しなかった後は、SOである力のオラクルに任せています。これらの方法のいずれかの経験、注意すべき問題点、まったく新しいことはありますか?

4

1 に答える 1

0

元のコードベースとはまったく異なる最終結果を伴う長期的な開発努力のために、私はしばしば「再統合フェーズ」を次のように見ました。

  • 新しいプロジェクトで開発された正確なコードにほとんどの時間を費やします (つまり、ほとんどの場合、実際のマージは関係なく、単純なコピーのみです)。
  • 履歴の使用が制限されています (つまり、新しいプロジェクトを元のプロジェクトに再統合するときに、新しいプロジェクトで行われたすべての中間コミットはもう必要ありません)。
于 2011-01-12T19:50:09.587 に答える