1

我们即将开始对一个新应用程序进行原型设计，该应用程序将与现有应用程序共享一些现有基础结构组件，并且还涉及现有域模型的重要子集。

对于这个新应用程序，部分领域模型可能会发生一些重大变化，所有这一切的最终结果是，一旦新应用程序被完全指定并准备好发布，我们希望重新统一模型两个应用程序（以及共享数据库、链接功能等），但在开发、原型制作等期间，我们将使用单独的数据库，以便我们可以更改内容而不必担心对开发或使用的影响现有的应用程序。由于它是一个原型，将有一个相当长的窗口，在此期间可能会发生严重的变化或重新架构，因为产品管理实验不同的工作流程，不同的客户群被调查，我们努力跟上。

为了不影响成熟应用的并发开发，我们已经做了一个 Subversion 分支，并且正在尝试两种潜在的推进方式：

  1. 使用 svn 分支作为唯一的分离机制。当我们确定长期运行的侧分支足够稳定以重新进入主干时，对现有域模型进行更改，并评估它们对现有应用程序的影响（并对 ProjectA 进行必要的更改）。

  2. “分叉”共享代码（临时）：将 ProjectA.Entities 复制到 NewProject.Entities，并将所有 NewProject 代码视为自包含的。当模型周围的所有扰动都消失并且我们感到满意时，手动将更改（如保证的细化或全面）重新集成到 ProjectA.Entities 中，更新 ProjectA 以在每个步骤中使用改进的模型（这可能需要放置在发生颠覆合并之前或之后）。然后，颠覆合并将不会处理此处任何重大更改的重组。注意：“fork”方法仅适用于我们在存储中看到显着更改的代码，并且其修改将破坏 ProjectA - 例如共享基础设施的东西，我们只需在原地修改（在我们的分支上）并让合并排序.

  3. 发展难，去购物。

自然，在没有达成协议后，我们将把它交给 SO 的权力神谕。任何这些方法的经验，需要注意的痛点，全新的东西？

4

1 回答 1

0

我赞成 2. 因为对于最终结果与原始代码库完全不同的长期开发工作，我经常将“重新集成阶段”视为：

  • 大部分时间都是在新项目中开发的确切代码（即，大部分时间不涉及实际合并，只是一个简单的副本）
  • 历史的有限使用（即，在将新项目重新集成到原始项目中时，我不再需要在新项目中完成的所有中间提交）。
于 2011-01-12T19:50:09.587 回答