Svn 持续集成的颠覆

对不起，如果这个问题的答案已经存在，我还没有找到

我是web开发团队的成员，我们维护一个web门户。发布管理与Subversion一起工作。这是我在向门户添加新功能时的工作方式：

• 通过复制主干创建新分支
• 在那个部门发展
• 定期将主干中的更新合并到该分支中（例如，在进行UAT/集成之前，我想知道框架更改是否会破坏我的代码。）
• 将分支重新集成到主干中，以使其生效

现在我们遇到了持续集成的问题：

• 每X周上线一次
• 有几个分支机构计划在不同的日期上线
• IntegrationServer每天每隔X小时进行一次主干签出，并将所有分支（应该明确地转到IntegrationSystem）合并到其中
• 已合并到每个分支中的主干更新（请参见上文）现在会生成树冲突

这方面的最佳做法是什么？重新集成不适用于合并多个分支，因为一旦集成了一个分支，工作副本就不再干净。然而，持续集成必须以某种方式实现

如果Trank更改合并到每个分支中，则会创建不同的修订。但是这些文件应该具有相同的内容并且是相等的。难道没有一个合并选项说“如果两个新的/更改的文件相同，则忽略冲突”吗

---

感谢您的帮助。

您所描述的是非持续集成，因为以下要求：

Integration Server每天每隔X小时进行一次主干签出和 合并所有分支（应显式转到集成系统） 投入其中

Real

连续集成

包括以下步骤：

• 从一个特定分支更新源代码（例如，

  trunk

  ）
• 生成生成可执行或部署的构建工件的源代码。有时，此阶段还包括运行单元测试和检查
• 显示生成状态，无论是否成功：绿色或红色

如果您有多个分支，这意味着您需要为多个分支配置多个构建计划，以便分别为每个分支执行连续集成

因此，您所描述的可能没有最佳实践，因为合并应该始终手动执行。这是由于合并冲突造成的。它们经常发生，只能手动解决。持续集成不会有帮助

如果您只是混淆了术语，并且想要执行您描述的内容，我会说您的开发过程有点缺陷。您可能不需要同时从多个分支执行合并。您最经常交付的所有开发都应该集中在一个分支中。通常，这样的“一个”分支是主干

在您的案例中，有价值的开发似乎分散在几个分支之间。那是不对的。一旦您决定某些功能应该包含在即将发布的版本中，它应该集成到一个（可能是父）分支中，并作为代码库的一部分留在那里。尽量减少分支机构的数量

总之,

从流程中排除

合并所有分支

步骤（这不是自动完成的）

请改为手动合并

如果您确定始终需要分支，请分别为每个分支配置连续集成

否则（您不需要一直保留分支，并且一旦开发完成，它们可以很容易地重新集成到父分支中）将分支数量减少到最小

---

祝你好运

我明白你的意思。如果分支应该上线，那么今天手动合并就可以了。我同意，单独的集成系统也应该可以正常工作。然而，我们的客户目前有一个UAT系统，他们在其中测试和批准变更。很难解释为什么他们现在应该在不同的系统中测试每个特性。。。还是我还错过了什么？你不需要解释什么。只需手动将其他分支的更改合并到主线分支（主干）。主线将具有您需要的所有更改/功能，因为您已经明确地合并了它们。因此，您可以直接在UAT上构建和部署主线内容，而不必担心遗漏了什么。不，抱歉，这是不可能的。在我们的环境中，将更改合并到主干中只意味着它们将在下一次部署中生效。这就是为什么我们在上线方面没有问题，但在UAT方面却有问题。此外：这并不意味着分支机构计划在下一次部署中投入使用，仅仅因为它在UAT系统上可用-它可以在那里停留很长时间（这可能是因为客户没有时间进行测试）。主干应该只反映实时资源。如果应用程序可以在UAT之前上线（生产），则流程存在严重缺陷。或者你的意思是说“上线”？从技术上讲，他们可以。当然，他们不应该。计划转到产品的更改必须从分支重新集成到主干中。因此，您提出的手动将所有分支合并到主干中的建议将有助于避免在Comprehensive UAT系统上发生冲突，但也意味着所有分支将在下一次计划部署时进入prod。换句话说：根据我们的概念，如果一个分支不能正常工作，就必须避免主干。有一个全面的UAT系统来显示所有分支机构的所有变化以实现“大审批”的问题仍然存在。。。顺便说一句：谢谢你的帮助！