Ber*_*arx 11 svn version-control branch web-applications branching-strategy
我正在尝试为Web应用程序项目确定最佳分支策略.以下是我到目前为止所提出的建议,我将非常感谢任何评论和经验.
我看到它的方式有两个主要的分支策略:"按版本分支"和"按功能分支".
"按发布分支":开发发生在主干上.当发布时间临近时,将为该发行版创建一个分支.然后稳定/测试该分支,最后进行释放.在发布之后,分支被合并回主干,同时保持发布分支活动以进行错误修复.是否应用了错误修复,然后将其合并到主干中(如果主干上的开发没有以其他方式使错误重叠).新功能将添加到主干中,不会影响发布分支.当新的发布时间临近时,将创建一个新的发布分支aso
"按功能分支":主干始终是"生产"主干(现场代码).错误修正直接提交到主干.下一版本的功能是在功能分支中开发的.Bugfixes会不时合并到功能分支中.当发布时间到来时,功能分支将合并到主干中,并且生命周期将继续.
现在,我认为这两种策略之间的实际区别在于,"发布"允许您维护软件的不同生产版本(当客户A具有版本1和客户B版本1.5时,客户端是此处的付费客户案件).相比之下,使用"按功能"策略,您只能支持当前的生产版本(所有客户端都使用最新版本).
由于在典型的Web应用程序中,所有客户端都使用相同的"最新"版本(因为它们都访问相同的服务器),我认为"按功能"方法是最常用的.它消除了合并"跨层次结构"的需要,比如说必须将bug修复应用于所有3个版本.
所以我目前的状态是我应该选择"逐个分支".如果重要,我的团队不是很熟练.
如果您在任何时候只有一个版本,并且您在一个功能分支中进行所有开发,那么这些方法实际上是相同的.
如果你逐个功能意味着马上有几个分支,我会像瘟疫一样避免它.更多的分支意味着更多的合并,这本身就是一种痛苦,而且更加融合地狱.连续集成到单个代码行要好得多.
如果您的部署过程比分支,测试,上线更为复杂,那么逐个发布的优势在于您可以在不同的阶段同时拥有多个发布分支:一个是实时的,并且根据需要进行了修复,以及另一个正在稳定,测试,通过验收等,而继续在后备箱上继续发展.另一方面,如果你有一个实时主干,一旦你将一个功能分支合并到一个视图中来实现它,你就失去了对当前实时系统进行错误修正的能力.功能分支合并成为一个不归路.
你在开发什么样的软件？收缩包装？开源项目？如果是这样,那么请使用"按释放分支"或"不稳定主干"方法.特别是如果你的发布周期是每隔六个月到一年.
但是,如果你维持一个基于网络的项目,这个项目在较短的频率上发生变化,比如每隔几周或更短一次,那么就采用"逐个分支"或"稳定主干"方法.这种方法的问题在于集成了多个功能更改,这些更改具有彻底的更改,使合并过程不那么有趣.这真的很难.
但这两种方法都运作良好,但如果你需要两者呢？也就是说,您有一个项目,每两周进行一次大型功能更改,但您发现有许多错误修复,您不能等待这些功能更改准备就绪.Trunk是您的发布分支,具有"按功能分支"方法.如果你能获得两个版本并拥有自己的分支怎么办？
查看CollabNet的Bob Archer撰写的博客文章.他的敏捷发布策略可以为您提供最佳解决方案.我用过这个.它非常灵活.尽管Bob没有在他的图表中显示它,但您可以同时拥有多个发布分支.这意味着您可以拥有一个已准备好部署到生产阶段的发布分支,以及另一个准备进行最终QA检查的发布分支.但要考虑两件事:
首先,您的开发人员合并有多好？即使它是一个小团队,您也无法自己执行敏捷发布策略方法.每个人都必须尽自己的一份力,他们真的必须了解合并以及他们用来进行合并的工具.
其次,你需要很好地掌握准备好的变化和即将变化的变化.发布管理是使这项工作像时钟工作的关键.准备好后,每个功能都需要分配给发布分支并合并到它.
无论您选择哪种方法,都可以归结为您正在开发的内容以及您为该开发发布的更改频率.