与 Subversion 中的多个分支开发持续集成

Question

在我正在进行的项目中，我们使用 SVN 和“稳定主干”策略。这意味着对于发现的每个错误，QA 都会打开一个错误票并将其分配给开发人员。然后，开发人员修复该错误并在分支（主干之外，我们称之为错误分支）中检查它，并且该分支将仅包含针对该特定的修复>bug Ticket

当我们决定发布时，对于我们想要向客户发布的每个错误修复，开发人员会将多个 bug 分支 中的所有修复合并到 trunk 并继续正常的 QA 周期。

问题是我们使用 trunk 作为 CI 作业的代码库 (Hudson ，具体来说），因此，对于对 bug 分支 的所有提交，它将错过每日构建，直到当我们决定发布新版本时将其合并到 trunk该软件。显然，这违背了 CI 的目的。

解决这个问题的正确方法是什么？

Answer 1

正如您所注意到的，使用分支的目的之一是将票务修复和功能开发中的特定代码波动与主干隔离开来。 但是一旦功能或票证完成，您应该将其合并回来。在 Subversion 中，分支更适合用来跟踪相关功能集（例如某个版本的功能集），而不是单个功能。否则，您很快就会遇到无法管理的分支数量。

此外，为什么要延迟整合呢？版本之间等待的时间越长，您的孤立更改与此后所做的另一个更改发生冲突的可能性就越大，并且/或在合并回来后在系统中产生进一步的不稳定。

我的首选策略是这样做：

    [begin work on 0.4 branch]
       |
       |
       v              
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable".
         \       |          |        Contains all commits.
    ver   \   [merge from trunk]     Developers commit to trunk.
<-- 0.3    \     v          v
            +---(a)--------(c)-- <-- Branch is "stable".
                                     Contains selected commits from trunk.
                                     Know beforehand what's going onto branch.

现在，一旦您准备好发布：

[trunk]
(*)---(*)---(*)----------------------------[development continues]--->


[0.4 branch]                        No further development on branch unless
(*)---(*)---(*)---[0.4-release]     spot fixes are needed. Then re-tag (0.4.1)
                          ^         and re-release.
                          |         
                          |
                       [make tag on branch; release from stable branch,
                        not unstable trunk]

我知道您询问了强制持续集成系统执行此操作的最佳方法。但我谨建议，鉴于 Hudson 被认为是一个相对有能力的 CI 系统，事实上，您在将开发模型硬塞到其中时遇到了很多麻烦，这可能表明这不是一个非常适合 CI 的流程首先。

我们的典型做法是每个项目有两个基础构建：一个针对主干，另一个针对当前发布分支。这样您就知道：

• 无论正在更新什么，都可以正确集成（trunk）
• 无论您的发布目标是什么，如果您现在停止工作，您仍然会拥有一个正确且有效的（只是功能不齐全）构建。

Answer 2

这就是我们所做的（灵感来自多个敏捷团队的版本控制 Henrik Kniberg）：

• 时，功能被推送到主干
• 开发是在开发分支中完成的，当“完成完成”主干是发布时的“完成”分支
• 我们标记主干
• ，当出现缺陷时， ，我们从标签
• 缺陷在发布分支中修补
• 补丁在发布后立即从发布分支合并到主干（以将其包含在未来版本中）

_{（来源：infoq.com< /a>)}

CI 在所有分支（开发分支、主干、发布分支）上运行。

Answer 3

这听起来很痛苦并且过于复杂（从分支/合并的角度来看）。

我会在发布时分支并让开发人员签入主干。任何需要作为热修复发布的内容都可以与发布分支合并。

Answer 4

每晚合并到一个“unstable-evil-twin-trunk”，将所有错误分支合并到evil-twin-trunk。

或者在每个 bug 分支上设置夜间构建（听起来像是很多夜间构建）。

在我看来，这听起来像是集中式源代码控制解决方案的大量分支。也许您需要一个分布式版本控制系统和每个工作站上的构建服务器，这似乎可以完成同样的事情（每个开发人员的独立签入和每日构建开发人员签入的内容）

Answer 5

与其为错误修复创建分支，不如尝试为错误修复之前的版本创建分支，然后将修复应用到主干。

这样，如果您想为客户提供错误修复，您可以为他们提供主干版本。
如果您不想向他们提供错误修复，您可以在应用修复之前向他们提供分支版本。

这样，您可以让 Hudson 构建干线，并且您的夜间构建将包括所有错误修复。

Answer 6

我回答了很多这个问题，下面是 IBM 如何使用 ClearCase (UCM) 推荐它，并且我在现实世界中这样做：

 - Project
    |-  development mainline 
    |-  TAG: version-1.0 
         |- version-1.0-bugfix#123 
         |- version-1.0-bugfixes 
    |-  TAG: version-1.0-sp1 
         |- version-1.0-sp1-bugfix#234 
         |- version-1.0.sp1-bugfixes 
    |-  TAG: version-1.0-sp2 

任何不以 TAG 为前缀的内容都是分支。