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

Question

在我正在进行的项目中,我们正在使用SVN和"稳定中继"策略.这意味着,对于找到的每个错误,QA会打开bug ticket并将其分配给开发人员.然后,开发人员修复了该错误并在分支中检查它(关闭主干,让我们称之为bug branch)并且该分支将仅包含该特定的修复程序bug ticket

当我们决定发布时,对于我们想要发布给客户的每个错误修复,开发人员将合并所有修复程序bug branch,trunk并继续正常的QA循环.

问题是我们使用trunkCI作业的代码库(特别是Hudson),因此,对于所有提交bug branch,它将错过每日构建,直到它合并到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 对多个敏捷团队的版本控制):

• 开发在开发分支中完成,当"完成"时,功能被推送到主干
• trunk是"完成"分支
• 在发布时,我们标记主干
• 当缺陷出现时,我们从标签创建一个发布分支
• 缺陷在发布分支中修补
• 补丁在发布后立即从发布分支合并到主干(在将来的版本中包含它)

CI在所有分支(开发分支,主干,发布分支)上运行.