具有持续集成的颠覆

Question

抱歉，如果这个问题的答案已经存在，我还没有找到。

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

• 通过复制主干创建一个新分支
• 在那个分支中开发
• 定期将主干中的更新合并到该分支（例如，在进入 UAT/集成之前，我想知道 Framework-Changes 是否会破坏我的代码）
• 将分支重新集成到主干中以使其上线

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

• 每 X 周定期上线
• 存在多个计划在不同日期上线的分支
• 每天每隔 X 小时，Integration Server 会执行一次 Trunk 检出并将所有分支（应明确转到 Integration System）合并到其中
• 已合并到每个分支（见上文）的主干更新现在会产生树冲突

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

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

感谢您的帮助。

Answer 1

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

每天每 X 小时，Integration Server 会执行一次中继结帐，并 合并所有分支（应明确转到集成系统） 进去

真正的Continuous integration 包括以下步骤：

• 从一个特定的分支更新源代码（例如trunk）。
• 构建源代码生成可以执行或部署的构建工件。有时这个阶段还包括运行单元测试和检查。
• 显示构建状态，无论是否成功：绿色或红色。

如果你有多个分支，则意味着你需要为多个分支配置多个构建计划，以便分别对每个分支进行持续集成。

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

如果您只是对术语感到困惑并且无论如何都想执行您所描述的内容，我会说您的开发过程有点缺陷。可能您不需要同时从多个分支执行合并。您最常交付的所有开发都应集中在一个分支中。大多数情况下，这样的“一个”分支是主干。

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

总结一下，

1. 从您的流程中排除 merge all branches 步骤（这不会自动完成）。
2. 请手动合并。
3. 如果您确定需要始终拥有分支，请为此类每个分支单独配置持续集成。
4. 否则（您不需要一直保留分支，一旦开发完成它们可以很容易地重新集成到父分支中）将分支数量减少到最少。

祝你好运！