颠覆与持续集成

Question

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

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

• 通过复制主干
创建新分支
• 在那个分支中发展
• 定期将Trunk中的更新合并到该分支中（我想知道Framework-Changes是否会破坏我的代码，然后再转到UAT / Integration，例如。）
• 将分支重新整合到主干中以使其生效

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

• 每X周定期上线
• 计划在不同日期上线的几个分支机构
• 每天X小时，Integration Server执行Trunk checkout并将所有分支（应明确转到Integration System）合并到其中
• 已合并到每个分支（见上文）的Trunk更新现在生成树冲突

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

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

感谢您的帮助。

Answer 1

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

  

每天每X小时，Integration Server执行一次Trunk checkout和   合并所有分支（应明确转到Integration System）   进入它

Real Continuous integration包含以下步骤：

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

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

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

如果你只是与术语混淆并且想要执行你所描述的内容，我会说你的开发过程有点缺陷。也许，您不需要同时从多个分支执行合并。您经常提供的所有开发都应集中在一个分支中。大多数情况下，这样的“一个”分支将是主干。

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

总结一下，

1. 从您的流程中排除merge all branches步骤（这不是自动完成的。）
2. 请手动合并 。
3. 如果您确定需要一直使用分支机构，请分别为每个分支配置持续集成。
4. 否则（您不需要一直保留分支，并且在开发完成后可以轻松地将它们重新集成到父分支中）将分支数量减少到最少。
祝你好运！