版本管理 [整理] 主干发布与分支发布模式

mandy.wang@aceona.com · 2011年09月08日 · 8 次阅读

软件发布方式大致可以分为两种:分支发布模式与主干发布模式。

[b][size=16px] 一.主干发布 [/b] [b] [/b] 先说主干发布模式: 以 SVN 库为例,大致将库分为 trunk, branch, tag 三种,主线发布就是公司要发布某个产品的 V1 版本,之前大家都做会在 SVN 的 trunk 上做开发,等 trunk 稳定了.开出一个分支 B1, 在 B1 分支上做 V1 版本的其它功能添加,bug 修改等,并使用持续集成来验证 B1 的稳定性.直到 V1 版本达到要求,可以对外发布,并且发布成功后,进行从 branch 到 trunk 的 merge 操作,此时 trunk 上的内容变成了 V1 版本的内容,而后 trunk 上的内容不再允许修改. 然后,再发布 V2,这个时候,比如下一个版本要发布 V2 版,这时从 trunk 的 V1 版发布的那个点,开一个分支 B2 出来,再进行 V2 版的开发,并做持续集成验证 V2 版的稳定性.直到 V2 版也达到要求,并且对外发布以后,将 B2 merge 到 trunk 上,此时的 trunk 上的内容又变成了 V2 版本的内容. 依次类推, 直到 V3,V4,V5 等. 我们称这种发布模式为主干发布,因为主干上的东西永远都是发布后的产品, 而且不允许修改. 如下图: [url=http://photo.blog.sina.com.cn/showpic.html#blogid=5eb1a2670100ewcs&url=http://s16.sinaimg.cn/orignal/5eb1a267h73081e3df17f&690img] http://s16.sinaimg.cn/bmiddle/5eb1a267h73081e3df17f&690[/img/url][] [b] 如果按照这种方式发布的优点:[/b]

第一:可以随时保证 trunk 上的东西的稳定性,使 trunk 随时可用;

第二:大部分开发人员不会去触碰 trunk,用分支的方式解决实际开发过程中的一些变更(需求变更或设计变更等);

第三:可以从 trunk 上随时拿到已发布的任意一个版本。

[b] 如果按照这种方式发布存在的不足:[/b]

第一:开发的时候, 持续集成一直在验证着 Branch 上的稳定性和正确性, 而对于 release 完成后 merge 到 trunk 上后, 没有对 trunk 进行集成验证, 难以保证 trunk 的稳定性;

第二:违背了 SVN 的规范,把 trunk 库当成了 tag 库去使用;

第三:某些开源项目会采用这种开发(发布)模式,但其中对于验证要求非常严格,merge 起来很费时,鉴于开源项目的特殊性,暂不做讨论;

第四:一般采用这种模式发布,是有自己的考虑在里面的。那就是 trunk 上的东西是不能损坏的,必须随时是好的,即使偶尔出现问题也能及时修正,但 trunk 已经完全失去了它做为主干的意义,也很难保证 SVN 库的一致性。

[b][size=16px] 二.分支发布 [/b]

再说分支发布模式: 以 SVN 库为例,大致将库分为 trunk, branch, tag 三种,所有开发人员基于 trunk 进行开发, 比如也是要发布 V1 版本的产品, 到 trunk 上的内容稳定后,版本达到了要 release 的要求,这时从 trunk 上开分支出来,我们可以称这个 B1 分支上的内容为 pre-release 版,此时这个 B1 分支只为 fix bug, 除非有必须要加的新功能.这个时候呢,大部分的开发人员就可以在 trunk 上开发下一次的发布, 而只需要少部分开发人员基于 B1 分支 fix bug.如果有 bug 需要在 B1 和 trunk 里面都 fix 的话, 就会有少量的 merge 操作,如非必要,就省心了. B1 分支开出来后, 一旦 release 了,可以根据发布计划,选择是否需要保留.如果近期有发 B1 的 update 计划,则可以保留;如果近期都不会再有基于 B1 的开发, 可以将 V1 发布这一时刻点的 B1 状态通过 tag 的方式记录下来,然后消亡 B1 分支.我们称这种模式为分支发布,因为分支才是发布的线,主干可以一直进行开发,而没有必要停止. 如下图: [url=http://photo.blog.sina.com.cn/showpic.html#blogid=5eb1a2670100ewcs&url=http://s12.sinaimg.cn/orignal/5eb1a267h71e737418b7b&690img] http://s12.sinaimg.cn/bmiddle/5eb1a267h71e737418b7b&690[/img/url][]

[b] 如果按照这种方式发布的优点:[/b]

第一:trunk 做为开发主线,开发人员可以随时将自己符合要求的代码提交到 trunk 上,如果在没有必要的条件下,不开分支。同时对 trunk 做持续集成验证,最大程度上保证 trunk 的稳定性。

第二:对每次成功的持续集成都同时对库和集成环境做 tag 操作,发挥 tag 库的强大作用。

第三:最大量的减少了 merge 操作,降低了误差。一旦要发布产品,只需从一个稳定的版本(公司上层同意的)发一个分支出来,然后再投入少量的开发人员去进一步优化,主要是 fix bug。而这时,大部分开发人员就可以投入到下一个版本的开发中,最大力度的使用人力资源。

第四:其它.

[b] 如果按照这种方式发布存在的不足:[/b]

第一:配置管理需要随时了解 pre-release 的分支是否需要保留,以为下一次发布 update 等做准备。

第二:如果有大型的变更,trunk 可能会被破坏,但是如果有一套规范,可以把风险降到最低。(或者也可以通过开分支的方式来解决这种问题)

第三:如果想要真正发挥这种发布模式的威力,配置管理,变更管理,持续集成,质量管理,发布管理每一个模块都是不可少的。

PS:依据 [url=http://bbs.scmroad.com/] http://bbs.scmroad. [/url][url=http://bbs.scmroad.com/] com [/url] 进行整理

xiaoxiang 博客的文章出自配置管理之路,然后又回到了配置管理之路:lol

跟我的原文是否有不一样的地方?如果有的话不防标注出来

图片没有处理好哈,罚款:lol

[[i] 本帖最后由 xiaoxiang7788 于 2011-9-9 09:34 编辑 ]

我特地去仔细读了原文,颇有体会。因为公司各个部门用不同的方式,有人喜欢用 HEAD,有人喜欢项目初始就创建分支,为了用统一他们,我要知道各个的利弊,好去说服。:)

你要请吃饭,xiaoxiang 会更高兴的。我也可以搭车,呵呵

不同性质的项目可以用不同的方法, 配置管理,变更管理,持续集成,质量管理,发布管理每一个模块都是不可少的。

我想请客,就怕你们不愿意花路费,呵呵。(我可不在北京哦:lol )

没事,也许某天我们就过去旅游了也不一定

需要 登录 后方可回复。