Ser*_*giu 38 version-control continuous-integration feature-branch featuretoggle
什么是"功能切换"和"功能分支"以及它们之间的区别是什么？
优缺点都有什么？为什么一个比另一个好？
我在Google上发现了一些关于此问题的文章,我倾向于参加"功能切换"阵营,但我不相信"功能切换"在所有情况下都是更好的选择.
小智 41
功能切换是持续集成/持续交付(CI/CD)链中使用的方法(敏捷/看板项目方法).基本上,您在禁用状态下将新功能发送到生产,然后在管理控制台中打开该功能(如果发现它已损坏,则关闭).
功能分支可以作为发布方法的一部分,并集成到持续集成链中.您可以在功能分支中进行开发,将分支部署到DEV/QA,获得认证,将功能分支合并到主干,然后将主干推送到SIT/UAT/PROD环境.
这种方法有利有弊.功能切换需要非常严格的规则,因为破碎/暗代码正在进行生产.这对于管理层知道如何实现这一目标并拥有系统自动化工具的初创公司和商店非常有用(Chef/Puppet/cfengine等)Google,Facebook,LinkedIn,WordPress都使用功能切换和系统自动化部署到生产环境.
有一些先决条件"技术人员"可以正常切换功能:持续交付/部署,持续集成,自动化单元测试,自动化集成测试,自动化压力/性能测试,系统自动化.如果您没有这些,请考虑更简单的发布策略(例如功能分支).
Dyl*_*ith 20
我在我的博客上深入讨论了这个问题:http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx
简而言之,功能分支将为您提供更好的隔离,但需要您处理延迟集成和合并的痛苦.Toggles为您提供持续集成,但要求您以支持切换的方式设计/实现代码,并引入未完成的功能代码可能对生产产生负面影响的风险.
您可以同时使用分支和切换(它们不是互斥的).至于决定在每个场景中使用哪一个,我的想法是切换应该是默认选择,除非以下是真的:
如果这些条件中的任何一个为真,我可能会使用功能分支而不是切换.
功能切换需要非常严格的纪律,因为破损/暗代码正在进行生产.
我同意Electrawn,我一直在使用功能分支6年,因为在我们的情况下,我们没有预先要求.
同样重要的是要了解"Toogle策略"将功能分支策略(合并)中花费的精力转移到另一个时刻.
http://martinfowler.com/bliki/FeatureToggle.html
一旦待处理的功能在生产中停工,退出切换是非常重要的.这涉及删除配置文件上的定义以及使用它们的所有代码.否则你会得到一堆没人能记住如何使用的切换.在我听说的一个令人难忘的例子中,它需要对linux内核进行特殊的重新编译以处理足够的命令行开关.
注意:遵循SCM原则,如果有人打开并编辑文件,则可能是代码损坏.
因此,在我看来,我不相信"在所有情况下都有更好的选择",因为这取决于你团队的文化以及你是否有测试封面.
那是一个非常暴力的问题.
在我的案例中,我仍然更喜欢功能分支策略.保持SCM最佳实践并规划路线图,合并过程往往是一种简单的方法.在这一年中,我听到很多人抱怨合并过程,但在很多情况下合并的问题在我的经验中是相同的,"沟通失败":)
很抱歉,这是一个非常准确的答案,但我认为在SCM这个更好的选择范围内有一些人类方面.
| 归档时间： |
|
| 查看次数： |
22697 次 |
| 最近记录： |