我们在交付新版本时的政策是在我们的VCS中创建一个分支并将其处理给我们的QA团队.当后者发出绿灯时,我们会标记并发布我们的产品.分支保持接收(仅)错误修复,以便我们可以创建技术版本.这些错误修复随后合并在主干上.
在此期间,主干会看到主要的开发工作,并且可能会受到重构更改.
问题是需要有一个稳定的主干之间存在紧张关系(以便错误修复的合并成功 - 如果代码已被提取到另一个方法,或者移动到另一个类,通常不能)在引入新功能时需要重构它.
我们的政策是在经过足够的时间之前不进行任何重构,并且分支足够稳定.在这种情况下,可以开始对主干进行重构更改,并在主干和分支上手动提交错误修复.
但这意味着开发人员必须等待一段时间才能在主干上进行任何重构更改,因为这可能会破坏从分支到主干的后续合并.并且必须手动将分支中的错误移植到主干上是很痛苦的.在我看来,这妨碍了发展......
你怎么处理这种紧张局势？
谢谢.
这是一个真正的实际问题.如果您需要支持多个版本并为每个版本分支,情况会变得更糟.更糟糕的是,如果你有一个真正的研发分支.
我的偏好是允许主干以正常速度继续运行而不是坚持,因为在商业发布时间非常重要的环境中,我永远无法争辩我们应该允许代码稳定("什么,你的意思是你把它释放到一个不稳定的状态？").
关键是要确保在错误迁移到主分支时,为错误修复创建的单元测试已经过渡.如果您的新代码更改真的只是重新分解,那么旧的测试应该同样有效.如果你的更改不再有效,那么你不能在任何情况下解决修复问题,你需要有人认真思考新代码流中的修复.
在管理这类问题的几年后,我得出结论,您可能至少需要4个代码流来提供适当的支持和覆盖,以及一系列非常严格的流程来管理它们之间的代码.这有点像能够用4种颜色绘制任何地图的问题.
我从未在这个问题上找到任何真正好的文献.它将不可避免地与您的发布策略以及您与客户签署的SLA相关联.
附录:我还应该提到,有必要将分支合并作为特定里程碑写入主分支的发布时间表.如果您有一群努力工作的开发人员在执行其工作实现功能,那么不要低估将您的分支机构聚集在一起所需的工作量.
在我工作的地方,我们为每个非平凡的变化(功能添加或错误修复)创建临时的,短期的(少于一天 - 几周)工作分支.Trunk稳定且(理想情况下)可能始终可释放; 只有已完成的项目才会合并到其中.从树干承诺的一切每天都会合并到工作分支中; 这可以在很大程度上自动化(我们使用Hudson,Ant和Subversion).(最后一点是因为通常比以后更快地解决任何冲突更好.)
我们使用的当前模型很大程度上受到Henrik Kniberg的一篇优秀文章(我之前已经插入)的影响:多个敏捷团队的版本控制.
(在我们的例子中,我们有两个scrum团队在一个代码库上工作,但我认为即使有一个团队,这个模型也是有益的.)
额外的分支和合并有一些开销,但不是太多,真的,一旦你习惯它并使用工具变得更好(例如svn merge --reintegrate很方便).不,我不会总是创建临时分支,例如,对于较小的,低风险的重构(与当前正在工作的主要项目无关),可以通过一次提交到主干来轻松完成.
我们还维护一个较旧的发布分支,其中不时修复关键错误.不可否认,如果代码的某些特定部分与分支相比显着地在干线中进化,则可能存在手动(有时是乏味的)合并工作.(随着我们不断向主干(内部)发布增量,并让市场营销和产品管理部门决定何时进行外部发布,这有望成为一个问题.)
我不确定这是否可以直接回答您的问题,或者您是否可以在您的环境中应用此问题(使用单独的QA团队和所有人) - 但至少我可以说您描述的紧张局势对我们来说并不存在,我们是随时可以自由重构.祝好运!
京公网安备 11010802040832号 | 京ICP备19059560号-6 