持续集成颠覆

Question

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

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

• 通过复制主干来创建新分支
• 在该分支中进行开发
• 定期将来自主干的更新合并到该分支中（我想知道框架更改是否会破坏我的代码，然后再进行更改）到 UAT / 集成，例如）
• 将分支重新集成到主干中以便让它上线

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

• 每 X 周定期上线
• 存在几个计划在不同的分支上上线的分支日期
• 每 X每天几个小时，集成服务器执行主干结帐并将所有分支（应明确地转到集成系统）合并到其中
• 已合并到每个分支（见上文）的主干更新现在生成树冲突

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

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

感谢您的任何帮助。

Answer 1

由于以下要求，您所描述的不是持续集成：

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

包括以下步骤：

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

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

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

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

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

总而言之，

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

祝你好运！