svn - 持续集成颠覆

Question

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

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

通过复制主干创建一个新分支

在那个分支开发

定期将来自主干的更新合并到该分支(我想知道框架更改是否破坏了我的代码，例如在进入 UAT/集成之前)

将分支重新集成到主干中以使其上线

现在我们有一个持续集成的问题:

每 X 周定期上线

存在几个计划在不同日期上线的分支机构

每天 X 小时，Integration Server 进行一次主干 check out 并将所有分支(应该明确地转到集成系统)合并到其中

已合并到每个分支中的主干更新(见上文)现在生成树冲突

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

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

谢谢你的帮助。

Answer 1

您描述的是不是持续集成 因为以下要求:

Every X hours a day, Integration Server does a Trunk checkout and merges all Branches (which should explicitly go to Integration System) into it

真实 Continuous integration包括以下步骤:

从一个特定分支(例如 trunk )更新源代码。

构建源代码生成可以执行或部署的构建工件。有时这个阶段还包括运行单元测试和检查。

显示构建状态，无论是否成功:绿色或红色。

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

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

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

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

总结，

排除 merge all branches从您的流程开始(这不会自动完成)。

改为手动合并。

如果您确定需要一直有分支，请分别为这样的每个分支配置持续集成。

否则(你不需要一直保留分支，一旦开发完成它们可以很容易地重新集成到父分支中)将分支数量减少到最低限度。

祝你好运!