Subversion与持续集成

Question

如果这个问题已经有了答案，请见谅，我还没有找到。

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

• 通过复制Trunk创建一个新的Branch
• 在该分支中进行开发
• 定期将Trunk的更新合并到该分支中（例如在它进入UAT/集成之前，我想知道框架变更是否会破坏我的代码）
• 重新将分支整合到Trunk中，以便让它上线

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

• 每X周定期上线
• 存在几个不同日期计划上线的分支
• 每天每X小时，集成服务器会检出Trunk并将所有分支（应明确进入集成系统的分支）合并到其中
• 现在已经将Trunk更新与每个分支合并（见上文），这些更新现在产生了树冲突

什么是最佳实践呢？重新整合对于合并多个分支是行不通的，因为一旦一个分支被整合，工作副本就不再干净了。然而，持续集成一定要有可能……

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

谢谢任何帮助。

- Michael Drewek

Answer 1

你描述的内容不是真正的持续集成，因为它有以下要求：

每天X个小时，集成服务器会进行Trunk检查并将所有分支（明确需要进入集成系统的）合并到其中。

真正的持续集成包括以下步骤：

1.从一个特定的分支（例如主干）更新源代码。

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

3.显示构建状态，无论成功或失败都会显示绿色或红色。

如果你有多个分支，那么你需要为每个分支配置多个构建计划，以便为每个分支单独执行持续集成。

因此，对于你所描述的情况，可能没有最佳实践，因为合并应该始终手动执行。这是由于合并冲突。它们经常发生，只能手动解决。持续集成无法帮助解决这个问题。

如果你只是混淆了术语而想要执行你所描述的操作，我会说你的开发过程可能有些错误。可能，你不需要同时从多个分支进行合并。你最常提供的所有开发应该集中在一个分支上。这样的“一个”分支通常是主干。

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

总之，

1.从你的流程中排除“合并所有分支”步骤（这不应该自动完成）。

2.手动进行合并。

3.如果你确定你需要一直保持分支，请为每个分支单独配置持续集成。

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

祝好运！

- altern

---

你只需要将其他分支的更改手动合并到主干分支中，而无需解释任何内容。由于你已经明确地合并了它们，主干分支将拥有你所需的所有更改/功能。因此，你可以毫不担心地构建和部署主干分支的内容到UAT上，因为没有任何遗漏。 - altern

不好意思，这是不可能的。在我们的环境中，将更改合并到主干只意味着它们将随着下一次部署而上线。这就是为什么我们没有上线问题，但有UAT问题。另外：仅因为分支在UAT系统上可用，并不意味着计划将其与下一次部署一起上线 - 它可能会在那里停留很长时间（这可能只是由于客户没有时间进行测试）。主干应该只反映实时资源。 - Michael Drewek

如果应用程序在用户验收测试之前可以上线（生产环境），则流程存在严重缺陷。或者你说的“上线”是指其他内容？ - altern

从技术上讲，他们是可以这样做的。但确信他们不应该这样做。计划部署的更改必须从分支重新集成到主干中。因此，您提议手动将所有分支合并到主干中，这将有助于避免在全面UAT系统上发生冲突，但也意味着所有分支都将随着下一个计划的部署一起进入生产环境。换句话说：根据我们的概念，如果一个分支不应该上线，就必须避免使用主干。仍然存在一个问题，即如何拥有一个全面的UAT系统，以显示所有分支的所有更改，以便进行“大型批准”...顺便说一句：感谢您的帮助！ - Michael Drewek

我完全明白你在这里说的话，Michael。这就是我最近所处的企业环境，我仍然对CI感到困惑。我们为特定分支设置了QA和UAT。有时，一个分支会被合并在一起进行进一步的测试。当我们计划进行Beta测试时，我们可以将QA/UAT通过的分支移动到根目录并开始Beta测试，基本上拥有根目录，直到我们的分支代码在下一个部署中。一些维护修复也可能被合并上来。 - J.T.