subversion中多分支开发的持续集成

正如您所注意到的,使用分支的一个目的是将特定的代码波动与票证修复和远离主干的特性开发隔离开来。 但一旦功能或票证完成,您应该将其合并回来。 在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 )
• 无论你的发布目标是什么,如果你现在停止工作,你仍然会有一个正确的工作(只是没有完全功能)的建设。

以下是我们的工作(灵感来自 Version Control for Multiple Agile Teams 亨里克·克尼伯格(Henrik Kniberg):

• 开发是在开发分支中完成的,功能在“完成”时被推送到主干中
• 主干是“完成”分支
• 在释放的时候,我们在后备箱上贴上标签
• 当出现缺陷时,我们从标记创建一个发布分支
• 在发布分支中修补缺陷
• 补丁在发布后立即从发布分支合并到主干(包括在将来的发布中)

ci在所有分支(开发分支、主干、发布分支)上运行。

从分支/合并的角度来看,这听起来很痛苦,也很复杂。

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

每晚合并到一个“不稳定的邪恶孪生树干”,合并所有的虫子分支到邪恶孪生树干。

或者在每个bug分支上设置nightly构建(听起来像很多nightly构建)。

在我看来,对于一个集中式的源代码管理解决方案来说,这听起来像是一个非常多的分支。也许你需要一个分布式版本控制系统和一个构建服务器在每个工作站上,它似乎可以完成同样的事情(每个开发人员的独立签入和基于开发人员签入的内容的日常构建)

与其为错误修复创建分支,不如在错误修复之前为版本创建分支,然后将修复应用于主干。

这样,如果你想让你的客户修复错误,你就给他们主干版本。 如果您不想给他们错误修复,可以在应用修复之前给他们分支版本。

这样,您就可以让哈德逊构建主干线,而您的夜间构建将包括所有的bug修复。

我经常回答这个问题,下面是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 

任何未加标记前缀的都是分支。